Cookie-based auth/authz with CSRF; remove auth bypass
Replace the dev-only token shim with real authentication. Backend: - @fastify/cookie; JWT carried in an HttpOnly + SameSite=Strict cookie (parking_token), read from the cookie not the Authorization header. - Double-submit CSRF: readable parking_csrf cookie + X-CSRF-Token header, both cross-checked against a csrf claim baked into the JWT; enforced on mutations. - Routes: POST /api/auth/login (bcrypt, constant-time-ish), POST logout, GET me. requireRole now verifies the cookie + CSRF + role. - seed-admin script (pnpm --filter @parking/server seed-admin) for the first admin; no bootstrap endpoint. - Removed SETUP_AUTH_BYPASS and catalog.authBypass entirely; setup endpoints use the cookie admin guard like everything else. Frontend: - apiFetch wrapper: credentials:'include' + X-CSRF-Token on mutations. - Login form; App gates on /api/auth/me and only shows setup to admins; logout. - Wizard token field removed (auth is the session cookie). Deploy: - deploy/nginx.conf: prod reverse proxy, SPA + /api same-origin, TLS, so the Secure cookies work. Dev stays same-origin via the Vite proxy. Verified (curl + browser): wrong pass -> 401; login sets cookies; me -> admin; assign without CSRF -> 403, with -> 201; no cookie -> 401; session persists across reload. wiki/local-jwt-auth updated.
This commit is contained in:
@@ -14,10 +14,27 @@ Authentication and authorization, kept **fully local** — a direct consequence
|
||||
- `@fastify/jwt` signs tokens with a **local secret** (symmetric HMAC). The server **refuses to
|
||||
start** without a strong `JWT_SECRET` (≥32 chars, no placeholder) — there is deliberately no
|
||||
insecure default — and mints tokens with an **8h expiry** (bound to a shift).
|
||||
- A `users` table in [[sqlite]] holds **bcrypt** password hashes plus a **role** column.
|
||||
- A `users` table in [[sqlite]] holds **bcrypt** password hashes plus a **role** column. The
|
||||
first admin is seeded via `pnpm --filter @parking/server seed-admin` (no bootstrap endpoint).
|
||||
- Authorization = a simple `preHandler` role guard per route: **admin / operator / cashier /
|
||||
readonly**. No Casbin or full RBAC engine needed at this scale.
|
||||
|
||||
## Cookie session (browser auth)
|
||||
|
||||
The SPA never sees the JWT. Login (`POST /api/auth/login`) verifies bcrypt and sets two cookies:
|
||||
|
||||
- **`parking_token`** — the JWT, **HttpOnly + SameSite=Strict** (+ `Secure` when
|
||||
`NODE_ENV=production`). JS can't read it; `@fastify/jwt` reads it from the cookie, not the
|
||||
`Authorization` header.
|
||||
- **`parking_csrf`** — a random token, **readable** by JS. The JWT also carries a matching `csrf`
|
||||
claim. On every mutation the SPA echoes the cookie in the **`X-CSRF-Token`** header; the guard
|
||||
requires header == cookie == the signed claim (**double-submit CSRF**). Safe reads are exempt.
|
||||
|
||||
Routes: `login`, `logout` (clears cookies), `me` (bootstraps SPA session on load). The dev
|
||||
[[react-vite-spa|Vite]] proxy and the prod **nginx** reverse proxy keep the SPA and API
|
||||
**same-origin**, so the cookies work without CORS. (This replaced an earlier dev-only
|
||||
`SETUP_AUTH_BYPASS` shim, now removed.)
|
||||
|
||||
> **Open decision:** moving from the symmetric secret to an **asymmetric key (RS256/EdDSA)** so
|
||||
> verifying hosts hold only a public key — [[open-questions]] #7. Relevant before any
|
||||
> multi-host/multi-lane deployment.
|
||||
|
||||
Reference in New Issue
Block a user