Maravilla Cloud Auth

platform.auth exposes both the public auth surface (register / login / OAuth / refresh / password reset) and the request-scoped identity binding that every protected handler must run.

The hosted auth pages at /_auth/login and /_auth/register set a __session cookie containing a JWT access token. Your server code's job is to translate that cookie into a bound identity for the rest of the request.

The 3-step contract — read this first

Every request that needs to act as an authenticated user must run these three steps in order:

1. validate(token) — confirm the JWT and return the AuthUser. If invalid, treat as anonymous.
2. setCurrentUser(token) — bind that identity to this request. Without this, every subsequent KV/DB/realtime/media op runs as anonymous, even though you have a valid AuthUser in hand.
3. (optional) can(action, resource, node?) — ask the policy engine, ahead of time, whether the bound caller is allowed to do something. The same evaluator gates direct ops, so can() is authoritative.

Skipping step 2 is the single most common Maravilla bug. Owner-scoped policies like auth.user_id == node.owner will see auth.user_id == "" and silently filter everything out. The UI shows an empty list. There is no error.

Canonical SvelteKit hooks.server.ts

This is the verbatim pattern from the demo app — every SvelteKit Maravilla project should have something equivalent: