Your site can have its own members: sign-up, login, magic links, roles, gated pages and per-row data access. Visitor accounts are stored in the site’s own database and are completely separate from the people who edit the site.
Build sign-up and login
Design the forms
Add inputs for email and password and bind them two-way to variables, for example
vars.emailandvars.password.Add a workflow
On the button’s click, run Sign up visitor or Log in visitor with those variables, then navigate to the members area. For passwordless, use Send sign-in link.
Show the right things
Bind visibility to
user.isLoggedIn, greet withuser.nameand add a button that runs Log out visitor.
The user scope
Every binding, workflow and rule can read user. A signed-out visitor is { isLoggedIn: false, id: NaN, roles: [] }, never null, so test user.isLoggedIn.
user = {
isLoggedIn: true,
id: 42,
email: "ada@example.com",
name: "Ada",
emailVerified: true,
roles: ["member"],
meta: {}
}
Email verification
A password sign-up does not prove someone owns the address, so accounts start with emailVerified: false. Opening a magic link sets it to true. If that account had a password, verifying clears it and ends its sessions: someone who signed up with another person’s email loses access as soon as the real owner signs in by link. Require verification where it matters, for example user.isLoggedIn && user.emailVerified.
Page access
With no element selected, the inspector shows the page settings. Turn on Restrict and write an access rule, such as user.isLoggedIn or user.roles.includes('admin'). Visitors who fail it are redirected to the page you choose, or get a 404.
- Rules are checked on the server for every request; gated pages are never served from the shared cache.
- Client queries of a gated page pass the same check, so its data cannot be fetched directly.
Roles
Define roles in Tables → Visitors and assign them there, or with the Set visitor roles server step (for example after a payment).