Accounts & authentication

Sites can have their own user accounts — visitors who register, log in, and access protected areas. This is built in, so you can create members' areas, client portals, and gated content without bolting on a third-party auth service.

User accounts

A site has a reserved table for its users. You can register and authenticate visitors, and store data against each account. Passwords are hashed for you — you never handle raw credentials.

Login and sessions

• Login, registration, and logout flows you wire into your own pages.
• Sessions keep a visitor signed in across requests, so their state and identity persist as they browse. See Sessions below.
• Token-based flows for things like password reset, email verification, and magic-link sign-in — short-lived, signed tokens you can issue and check.

Protected areas

You can require authentication for whole sections of a site — a folder of pages becomes members-only — and apply finer-grained checks in your handlers for role- or permission-based access. Unauthorized visitors get a custom error page rather than a broken one.

Sessions

Beyond login, sessions give every visitor server-side storage that persists across requests — useful for shopping carts, multi-step forms, and preferences, whether or not the visitor has an account. Most session data stays server-side; you can explicitly expose selected values to the browser when your front-end needs them, and sensitive keys are kept server-only.

Client portals

Put together, these features are what you use to build client portals: a login page, protected dashboards, per-client data, and secure file sharing — a common pattern for agencies giving each client a private area on their own site.