- Verschifft
- 24. September 2026 um 00:15 UTC
- Autor
- Kamo
- Ausschuss
- b0e08ac
kamo-internal is moving the *** session id out of browser JavaScript: it currently sits in sessionStorage and rides every WebSocket URL as `?***=<128-hex id>`, which Traefik's access log records in full. Browser WebSockets will instead carry a short-lived one-time key that kamo-internal mints (POST /api/generate-otk): Redis `OTK<otk>` -> the 128-hex *** id. Both services need to accept it before kamo-internal switches over, so this ships first. WebSocketAuthInterceptor now reads an `otk` query parameter and resolves it through **************** (new, alongside the existing consuming validateAndConsumeOneTimeKey used for X-OTK): this is a SockJS endpoint, so one browser connection can make more than one handshake as it probes transports, and a consuming read would break the fallback — the key's own short TTL bounds it instead. Precedence is otk, then the legacy *** query param, then the *** cookie. An otk that is present but does not resolve is a hard reject: it never falls through to *** or the cookie, which belongs to whichever tab refreshed last and would otherwise silently authenticate a different session. Nothing past session resolution changes (member eligibility, attributes). The otk and resolved id are never logged, matching the surrounding code. Tests: KSessionServiceOneTimeKeyTest and WebSocketAuthInterceptorTest cover otk resolution and non-consumption, the reject-on-unresolved-otk precedence rule, legacy *** still working, and no-credential rejection. Both the precedence rule and the no-delete rule were mutation-checked by hand (reverting each to the old/buggy shape reproduces a red run).