fix: stop exposing the Knox session token to page JavaScript

[TheoBhang]

Problem

The SPA persisted its Knox auth token in localStorage (reducers/auth.js), and for SSO logins the OIDC callback handed the raw token to the browser via a ?sso_token=... query parameter before the SPA moved it into localStorage (accounts/oidc_views.py, frontend/src/components/App.js).

Both are readable by any script running on the page — a single XSS finding (stored, reflected, or via a compromised npm dependency) is a full account takeover, no separate bug needed. The URL-param handoff also means the raw token briefly transits as a query string: visible in the OIDC callback's 302 Location header, in browser history until window.history.replaceState fires, and in any proxy/access log sitting in front of the deployment.

Fix

Mirrors the pattern already shipped on Thales CERT's Suspicious platform (api/authentication.py::KnoxCookieAuthentication / _set_auth_cookies):

• accounts/authentication.py (new): KnoxCookieAuthentication, reading the token from an httpOnly, SameSite=Strict cookie. Falls through to header-based knox.auth.TokenAuthentication when the cookie is absent, so existing non-browser API clients using the Authorization header are unaffected.
• accounts/api.py: LoginAPI now sets the cookie on login (in addition to the existing JSON token field, kept for non-browser clients). Added LogoutAPI to clear both cookies and delete the token server-side — knox's stock LogoutView has no notion of the cookie, so it was routed ahead of knox.urls's own logout path in accounts/urls.py.
• accounts/oidc_views.py: SSOCallbackView now sets the cookie server-side and redirects to /?sso=1 — the token no longer appears in the URL at all.
• watcher/settings.py: KnoxCookieAuthentication registered ahead of header auth in REST_FRAMEWORK.DEFAULT_AUTHENTICATION_CLASSES.
• Frontend: reducers/auth.js, actions/auth.js, and components/App.js no longer read/write the token via localStorage. Also caught and fixed two more call sites that would otherwise have silently broken — contexts/ThemeContext.js and services/preferencesService.js were independently reading localStorage.getItem('token') to hand-build Authorization headers for theme/preference sync; both now rely on the cookie like everything else.

Unrelated build fix bundled in

While testing this through a full local deployment, discovered npm run build has been silently broken (reproduced against the unmodified base commit too, not caused by this change): webpack fails with ERR_REQUIRE_ESM because babel-loader@10.1.1 does a synchronous require() of @babel/core@8.0.1, which ships as pure ESM. Root cause: @babel/core@8's own transitive deps require Node ^20.19.0 || >=22.12.0 (synchronous require(esm) support), but the Dockerfile's frontend-builder stage was pinned to node:18-bookworm-slim. Fixed by bumping to node:22-bookworm-slim and adding an explicit engines.node constraint to package.json — confirmed this alone fixes the build with zero package downgrades. Rebuilt and committed the frontend bundle, which is also the first rebuild since this fix, so it's the first bundle that's actually free of the localStorage token usage above.

Test plan

• python manage.py test accounts — new KnoxCookieAuthTest (login sets both cookies, cookie alone authenticates with no Authorization header, logout clears both and invalidates the token) plus all pre-existing accounts tests, run inside the built image against real MySQL: 8/8 passing.
• python manage.py test (full suite) run the same way: 250/250 passing, no regressions.
• Built the actual Docker image from this branch and deployed it (LDAP-backed auth against a real directory) — live-verified with curl: login sets Set-Cookie: knox_token=...; HttpOnly; SameSite=Strict, GET /api/auth/user authenticates via cookie alone (no Authorization header sent), logout clears both cookies, and a replayed post-logout cookie correctly gets 401.
• Confirmed the shipped JS bundle no longer contains loginWithToken, sso_token, or any localStorage-token pairing.