Who can reach it

Settings › Access. Three answers, set per application, because they are answers to genuinely different questions.

You are also asked when the application is created, and it is worth answering then rather than later: an application people sign in to needs sign-in screens and knows who is looking, one behind a shared password needs neither, and changing your mind after the screens exist means building them twice.

Decide later, in that wizard, is a real answer rather than a way of skipping. The builder raises it once during the first build, when it can say what each of these would mean for your application in particular, and applies what you choose. Answering it here instead, at any point, takes the question away.

Anyone with the address#

A public site. Everything in it is readable by anyone who finds it. The default.

Right for a marketing page, a public form, a status board. Wrong for anything with a customer's data in it.

One shared password#

Everyone types the same password once. Nothing to set up per person, nobody to enrol.

Right for showing a client their application before it is public, and for an internal tool that does not need to know who is using it.

Choosing it generates a password and applies it there and then. The password is shown rather than dotted out, with an eye to hide it — you are the person who has to pass it on, and a field you must reveal before you can copy it is ceremony borrowed from sign-in forms, where the threat is somebody standing behind you.

It is stored hashed, so once you leave that screen it cannot be shown again, only replaced.

People sign in#

Accounts, one per person, with two-step sign-in if they want it. The application needs sign-in screens, which the builder can add — ask for them.

See People who sign in.

Where the check happens#

All three are enforced in front of the application, not inside it. That matters more than it sounds:

• it covers every page, every API route and every file the application publishes, including ones a later build adds;
• it holds while the application is being deployed, or while its build is broken;
• the application cannot turn it off by accident, because it is not the application's to turn off.

Somebody who does not have the password gets the password form on the address they asked for, so the link they were sent still works once they are in.

Test and live are separate doors#

The shared password is per environment, and so are the sessions it creates. A client shown the test copy has not been shown the live one.

What stays reachable without the password#

robots.txt and the password form itself. Nobody can type a password on a page they cannot load.

Choosing#