The BFF trust boundary
How auth actually works, prose bound to the server code: the global guard, the httpOnly cookie session, and the authed client that refreshes on 401.
3. Architecture — the backend-for-frontend (BFF)
The browser talks only to Donna's SvelteKit server. That server:
- Holds the lq-ai JWT access + refresh tokens in httpOnly cookies (never exposed to client JS).
- Attaches
Authorization: Bearerwhen proxying to the lq-aiapi, and transparently refreshes on401. No CORS anywhere. - Is the single trust boundary: auth lives in
src/hooks.server.ts+src/lib/server/.
Consequences you must internalize:
- Server-only code (cookies, the authed
lqClient, auth wrappers) lives undersrc/lib/server/. Never import it into client code. - A page gets backend data through a SvelteKit
load(SSR) and mutates through form actions or small BFF proxy routes (+server.ts) — not by calling lq-ai from the browser. - Proxy routes exist to (a) attach auth and (b) avoid page/endpoint route collisions — e.g.
/prompts/itemssits beside the/promptspage, and the/tabular-executions/[id]proxy is a separate top-level group precisely so it doesn't collide with the/tabular/[executionId]page.