- Szycy
- 24 września 2026 00:15 UTC
- Autor
- Kamo
- Pochęt się
- 279723a
Same change as mediaservice: kamo-internal is moving the *** session id out of browser JavaScript, off sessionStorage and off every WebSocket URL (`?***=<128-hex id>`, recorded in full by Traefik's access log) and onto a short-lived one-time key it mints via 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. 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).