KamoCRM

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

FixEmailService
Name
lúc 00:15 24 tháng 9, 2026 UTC
Tác giả
Kamo
Cam kết
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).

Mọi thay đổi

Như những gì anh thấy vận chuyển?

Tất cả những thứ đó đều đến trong không gian làm việc của anh. Bắt đầu với kế hoạch miễn phí và đọc lại trang này trong một tháng.

Bắt đầu tự do mãi mãiXem truy cập