- Enviado
- 24 de septiembre de 2026 a las 0:15 UTC
- Autor
- Kamo
- Commit
- 279723a
Mismo cambio que el servicio mediático: kamo-internal está moviendo el *** sesión id fuera del navegador JavaScript, fuera de sesiónStorage y fuera de cada URL WebSocket (`?***= se registró en su totalidad por el registro de acceso de Traefik) y en un llave de una sola vez cortada que miente a través de POST /api/generate-otk. Redis `OTK secuestró `` - propiedad el 128-hex *** id. Ambos servicios necesitan aceptarlo antes Kamo-internal cambia, así que esta nave primero. WebSocketAuthInterceptor ahora lee un parámetro de consulta 'otk' y lo resuelve - ¿Por qué? (nueva, junto a validación de consumo existenteAndConsumeOneTimeKey utilizado para X-OTK: esto es un SockJS endpoint, por lo que una conexión del navegador puede hacer más de un apretón de manos a medida que proba el transporte, y una lectura que consume rompería el retroceso - el La llave es muy corta. Precedencia es otk, luego el legado *** query param, luego la galleta ***. Un otk que está presente pero no resuelve es un duro rechazo: nunca cae a *** o la cookie, que pertenece a cada pestaña refrescada ultimo y de otra manera autenticar silenciosamente una sesión diferente. Nada. cambios en la resolución del período de sesiones anterior. El otk y el id resuelto nunca se han registrado, coincidiendo con el código circundante. Pruebas: KSessionServiceOneTimeKeyTest y WebSocketAuthInterceptorCubierta más alta otk resolución y non-consumption, the reject-on-resolved-otk precedence regla, legado *** todavía trabajando, y rechazo no-credencial. Ambos la regla de precedencia y la regla de no-delete fueron verificadas mutación a mano (revertir cada uno a la forma vieja/perrito reproduce una carrera roja).