- Expédié
- 24 septembre 2026 à 00:15 UTC
- Auteur
- Kamo
- Commit
- 279723a
Même changement que mediaservice: kamo-internal déplace l'id *** session hors du navigateur JavaScript, hors sessionStorage et hors de chaque URL WebSocket (`?***=<128-hex id>`, enregistré en entier par le journal d'accès de Traefik) et sur un clé unique de courte durée il ment par POST /api/generate-otk. Redis `OTK<otk>` -> le 128-hex *** id. Les deux services doivent l'accepter avant les interrupteurs internes de kamo, donc ce vaisseau d'abord. WebSocketAuthInterceptor lit maintenant un paramètre de requête `otk` et le résout à travers **************** (nouveau, à côté de consommation existante valideAndConsumeOneTimeKey utilisé pour X-OTK): SockJS endpoint, donc une connexion de navigateur peut faire plus d'une poignée de main comme il sonne transporte, et une lecture consommatrice briserait le recul — le la clé est propre court TTL le limite à la place. La priorité est otk, puis l'aléatoire ***, puis le cookie ***. Un otk qui est présent mais qui ne résout pas est un dur rejet: il ne tombe jamais jusqu'à *** ou le cookie, qui appartient à l'onglet rafraîchi et authentifierait en silence une session différente. Rien les modifications apportées à la résolution de la session précédente. L'identifiant otk et résolu ne sont jamais enregistrés, correspondant au code environnant. Tests: KSessionServiceOneTimeKeyTest et couverture WebSocketAuthInterceptorTest otk résolution et non-consommation, le rejet sur non-résolu-otk priorité la règle, l'héritage *** fonctionne toujours, et le rejet sans fondement. Les deux la règle de préséance et la règle de non-suppression ont été contrôlées à la main (rétrograder chacun à la forme ancienne/buggy reproduit un run rouge).