iOS Safari in PWA standalone mode unreliably handles cookies, causing
CSRF token desync between client and server after app resume. Previous
fixes (response body token in /auth/me and /auth/login) still left a
window where the token could go stale.
Now the server sends X-CSRF-Token response header on every API response
(via csrfMiddleware), including 403 error responses. The client reads
this header from every response, enabling instant self-healing: a 403
extracts the correct token from the error response itself and retries
without needing an extra /auth/me round-trip.
SW cache bumped to v33 to ensure existing iOS PWA installs pick up the
new client code.
Safari's ITP blocks Strict cookies on certain navigations (direct URL entry,
reverse proxy context), resulting in a 401 on login even with valid credentials.
Lax is safe: CSRF attacks are prevented by the double-submit token and the
HTTPS-only secure flag. Firefox and Chrome were unaffected.
Convert all server/, test, and setup files from require()/module.exports
to import/export syntax. Activate ESM globally via "type": "module" in
package.json and load dotenv via --import dotenv/config in npm scripts.
Cookies were sent without Secure flag outside of production (NODE_ENV check).
New logic: secure=true by default; set SESSION_SECURE=false in .env to
allow HTTP explicitly (local dev without reverse proxy). Affects session
cookie, CSRF cookie in login handler, and CSRF middleware.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- router.js: navigateTo() existierte nicht → ReferenceError nach fehlgeschlagenem
auth.me(). Ersetzt durch navigate() + currentPath-Reset damit die Weiterleitung
nicht durch den currentPath-Guard geblockt wird.
- csrf.js: SESSION_SECURE=false wurde nicht berücksichtigt → CSRF-Cookie war über
HTTP nicht für JS lesbar → alle schreibenden API-Calls nach Login scheiterten mit 403.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Rafael Foster