- Shipped
- 24 settembre 2026 alle ore 00:15 UTC
- Author
- Kamo
- Commit
- 279723a
Stesso cambiamento di mediaservice: kamo-internal sta muovendo il *** sessione id fuori del browser JavaScript, off sessionStorage e off ogni WebSocket URL (`?***= <128-hex id>`, registrato in pieno dal registro di accesso di Traefik) e su un chiave una volta breve che mints via POST /api/generate-otk. Redi > il 128-hex *** id. Entrambi i servizi devono accettarlo prima kamo-internal passa, quindi questa nave prima. WebSocketAuthInterceptor ora legge un parametro di query `otk` e lo risolve E' il momento giusto. (nuovo, accanto al validateandConsumeOneTimeKey usato per X-OTK): questo è un SockJS endpoint, quindi una connessione del browser può fare più di una stretta di mano che sonda i trasporti, e una lettura consumante romperebbe il fallback — il La chiave è proprio breve TTL lo lega invece. Precedence is otk, then the legacy *** query param, then the *** cookie. Un otk che è presente ma non risolve è un rifiuto duro: non cade mai attraverso il *** o il cookie, che appartiene a qualsiasi scheda rinfrescata ultimo e altrimenti autenticare silenziosamente una sessione diversa. Niente. modifiche della risoluzione della sessione precedente. Il otk e id risolti non sono mai registrati, corrispondente al codice circostante. Test: KSessionServiceOneTimeKeyTest e WebSocketAuthInterceptor otk risoluzione e non consumo, la priorità respinta regola, eredita', ancora funzionante, e nessun rifiuto riservato. Entrambi la regola di precedenza e la regola di no-delete sono stati controllati a mano (revertendo ciascuno alla forma vecchia/buggy riproduce una corsa rossa).