fix: enforce CSRF session-binding, propagate refreshed token, server-deliver rate alerts (#486, #487, #469)

[stephanieoghenemega-eng]

Resolves #486, Resolves #487, Resolves #469 — a full pass over CSRF session-binding, real access-token refresh, and server-backed FX rate alerts.

#486 — CSRF is now session-bound and enforced

• verifyCsrfRequest() (lib/utils/csrf.ts) enforces two checks on every state-changing request to our own API routes:
  1. double-submit — X-CSRF-Token header must equal the csrf_token cookie (constant-time compare);
  2. session binding — when a csrf_sid cookie exists it must equal sha256(csrf_token . sessionKey(auth_token)). A csrf_token minted for a different visitor or a pre-login page carries the wrong csrf_sid, so it is rejected once a real session is in play. Sessions predating the binding fall back to double-submit only and are upgraded on their next login/refresh (no lock-out).
• Enforced on POST /api/rate-alerts, PATCH/DELETE /api/rate-alerts/:id, POST /api/rate-alerts/evaluate.
• Rotation on logout — authStore.logout() calls rotateCsrfToken() (GET /api/auth/csrf?rotate=1) after clearing the session, so the token changes after logout, not only after login.
• Login (POST /api/auth/session) and refresh (POST /api/auth/refresh) already rotate both csrf_token and csrf_sid together.

Verify: capture csrf_token before login → log in → it changes and csrf_sid appears. Log out → it changes again. Set the old csrf_token cookie + header by hand and POST /api/rate-alerts → 403 CSRF validation failed.

#487 — the refresh route's new token now reaches the client

POST /api/auth/refresh returns { refreshed, token } on a real rotation. Previously nothing consumed token, so the axios request interceptor's local JWT-expiry pre-check kept rejecting follow-up requests against the stale in-memory token.

• axios single-flight now reads the response and useAuthStore.getState().setToken(token) before replaying the queued requests.
• SessionTimeoutModal → extendSession() does the same, and a 401 from refresh (dead refresh token) logs out + redirects once — a hasRedirectedForExpiry guard stops a burst of queued 401s each firing their own redirect + toast.
• Both callers send the CSRF header on the refresh call.

Verify: network tab — "Extend session" shows /api/auth/refresh returning a new token; the next API call carries the rotated cookie and succeeds. Kill the refresh token server-side → one redirect to /auth/login, one toast at most.

#469 — rate alerts are server-backed with real delivery

• lib/server/rateAlerts.ts — shared per-merchant store + evaluateAlerts(): condition match, optional HH:MM time window (wraps past midnight), per-alert delivery dedupe (DELIVERY_DEDUPE_MS), one-time alerts deactivate after firing, recurring re-arm. In-app deliveries land in the notification store immediately (with its existing dedupe); email/webhook deliveries are recorded as queued for the feature-Add useCallback for event handlers in dashboard and settings #38 worker.
• POST /api/rate-alerts/evaluate { pair, rate } — the FX page feeds the live rate; the server fires + delivers + dedupes and returns the authoritative list.
• rateAlertStore — addAlert optimistically inserts then POSTs and swaps in the server id; toggle/delete propagate for synced rows; hydrateFromServer() restores alerts on boot so they survive a reload; evaluate() reconciles from the server.
• FX page — the create form gains one-time / recurring, in-app / email / webhook channels, and an optional fire-only-within time window; alert rows show all three. The old client-only trigger check remains as an offline fallback and never double-delivers (the server owns triggered for synced rows).

Verify: set an alert, reload → it's still there (from GET /api/rate-alerts). Move the rate past the target → one delivery (in-app notification appears once even across repeated evaluations); a one-time alert flips to disabled.

---

Notes

• Builds on the merged fix(auth): session-persist consistency + hydration gate, CSRF session-binding, real refresh route; server-backed rate alerts (#485, #486, #487, #469) #650 (same author) rather than replacing it: that PR added the CSRF binding cookies, the refresh route's backend exchange and the first rate-alert routes. This PR closes the acceptance-criteria gaps it left — enforcement + logout rotation (CSRF token is reused across login/users with no per-session binding #486), token propagation into the client (Session refresh route is a stub and never refreshes the access token #487), and delivery/dedupe/UI (Recurring & scheduled FX rate alerts #469).
• In-memory server stores (alerts, notifications) follow the repo's existing globalThis pattern; swap for tables before production.
• npm run build / the jest suites were not run in this environment; changes follow existing patterns and the store/hook unit tests' contracts (sync addAlert, extendSession return shape) are preserved.

🤖 Generated with Claude Code

[vercel]

@stephanieoghenemega-eng is attempting to deploy a commit to the therealjhay's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@stephanieoghenemega-eng Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits