KamoCRM

Accept a short-lived otk on the WebSocket handshake, alongside ***

FixMediaService
Ya
24 Septemba 2026, 00:15 UTC
Mwandishi
Kamo
Ahadi ya
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).

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila kitu kinaingia kwenye tovuti yako mwenyewe. Anza kwenye mpango wa bure na usome ukurasa huu tena katika mwezi mmoja.

Kuwa Huru MileleMtazamo wa bei