Visitor sign-in in apps

With the auth.customer capability, an app can sign visitors in with their customer account: the same account they use in your shop and on members-only pages. Sign-in is the site's own secure cookie session. The app never sees or stores a token, and it only ever sees the signed-in visitor's own profile and roles.

Praisma.auth

await Praisma.auth.register({ email, password, password_confirmation: password, first_name, last_name }); await Praisma.auth.login({ email, password, remember: true }); try { const { data: me } = await Praisma.auth.me(); // me = { id, email, first_name, last_name, full_name, roles: [{ id, name }], ... } } catch { // signed out } await Praisma.auth.updateProfile({ first_name: "Ana" }); await Praisma.auth.changePassword({ current_password, password, password_confirmation }); await Praisma.auth.forgotPassword({ email }); await Praisma.auth.resetPassword({ email, token, password, password_confirmation }); await Praisma.auth.logout();

Registering with an address that already has an account does not reveal it: the answer is generic and the person receives a password-reset email instead.

If self sign-up is turned off for the organization,registeris refused and staff create customers instead.

Sign-in attempts and password resets are rate limited.

After a sign-in or sign-out, the rest of the site (account blocks, content shown only to signed-in customers) updates too.

Locking the app

In Code Builder, Access sets who may open the published app, just like a page's access: public, members (any signed-in customer) or specific customer roles. List the routes guests may still open, such as /login, /register and /reset-password/*, and point the redirect at your sign-in screen. Changes apply immediately, without republishing.

A guest who opens a locked screen is redirected with ?next=. After sign-in, send them back:

await Praisma.auth.login({ email, password }); window.location.assign(Praisma.auth.nextUrl() || "./");

Your own route guard (for example, redirecting when me() rejects) is only for a good experience. The real protection is the server lock for screens and each collection's customer access rules for data.

Collection rules for visitors

In the CMS, each collection's Customer access decides who may read and write it from apps and the site: for example read by everyone, by members, by roles, or only the entries a visitor created themselves, and update or delete only by the entry's owner. These rules add a sign-in requirement on top of the app's approved access.