User accounts & login
Give the app you build its own sign-in — so your users can register, log in, and see their own data. This is separate from your Likeable login (that's your account); this is the accounts inside the product you ship. It also covers the cookie-consent banner most apps need.
The fastest way: tell the builder "add login to my app" (or "let users sign up and only see their own orders") and it wires everything below.
Set it up
One step configures the whole flow — the builder calls it for you:
- Cloudflare (zero-config) — uses a built-in D1 database for users; nothing to provision.
- Your own database — point it at a Postgres connection; create the users table once
(the builder gives you the exact
CREATE TABLE app_users …to run).
This creates four backend operations — sign up, log in, log out, me (who am I) — and the
app_users table.
Set LIKEABLE_AUTH_SECRET in your deployment's environment — it signs the session tokens. It's listed in
the generated .env.example / .dev.vars.example; set it with wrangler secret put or your host's env. Never
put it in chat. Passwords are PBKDF2-hashed and the session is an HttpOnly signed cookie — never readable
by browser JavaScript.
The bricks
- AuthForm — a sign-in / sign-up form, or a sign-out button (
mode= login | signup | logout). On success it records the signed-in user; the server sets the session cookie. - AuthGate — wrap anything you want to protect. Its contents show only when signed in; otherwise it shows a sign-in prompt. A returning user with a valid session is recognized automatically on load.
A typical app: a Login page with an AuthForm (login) + a link to a Signup page; the dashboard wrapped in an
AuthGate; a "Sign out" AuthForm (logout) in the header.
Show each user only their data
Combine login with the data layer: mark a query as requiring auth and scope it to the
current user. The logged-in user's id is injected server-side as __userId (a client can't fake it), so:
SELECT * FROM orders WHERE owner_id = $1 -- bound to the logged-in user (__userId)
Each signed-in user sees only their own rows. The same applies to writes (insert with the user's id) and to the AI assistant (its data tool runs as the user).
Cookie consent
Add a CookieBanner brick once near the top of your app. It shows a consent notice, remembers the choice, and records it so your analytics/marketing bricks can check it before running. The login session cookie is strictly necessary and needs no consent — the banner governs the non-essential cookies. Set a link to your privacy policy on the brick.
Deploying
End-user auth runs on Node hosts (Vercel/Netlify/Lambda/persistent server) and Cloudflare (with D1) —
the auth engine is edge-safe. In the builder preview the form simulates a signed-in user so you can design
the logged-in and logged-out states; real authentication runs once the app is deployed (with
LIKEABLE_AUTH_SECRET set).
Next steps
- Databases & SQL — the data each user owns
- AI chat & agents — an assistant that answers per-user
- Deploying — publish your app