- Navios
- 19 de agosto de 2026 às 02:19 UTC
- Autor
- Kamo
- Enviar
- f760aef
O KToken não pôde verificar um item real. Os quatro IDs que carrega são int64s, e o Java singer (kamo-shared-library KToken# canonicalForMac) adiciona cada um como um 'long' em bruto, então tudo 19 dígitos vão para o material MAC. Esta classe lê- as com o Number (), que passa 2^53, e cada setter então aplicado `v'0` -- um truncamento de 32 bits no topo do arredondamento. 1168485648209608710 saiu como um número inteiro pequeno, o HMAC recomputado não correspondeu ao um o servidor assinado, e analisarAndVerifyCookie retornou null: um token válido lido como Forjada. Ele só concordou consigo mesmo, em identidades suficientemente pequenas para representar. Os IDs são agora as strings de dígitos do próprio cookie, então o material corresponde ao byte do sinalizador para byte, e são validados por forma em vez de por Number(), o que iria derrotar o Ponto. A expiração permanece um número -- os segundos de época são ~1.8e9 e não correm perigo. Nada chama de parseAndVerifyCookie hoje; o cookie é encaminhado para os serviços verbatim. Isto corrige uma mina em vez de uma falha -- mas é uma mina em uma auth path, onde a falha pareceria um login rejeitado em vez de um bug de arredondamento. A mesma alteração que o kamo-internal f55a95c9, onde carrega testes comprovados por mutação: 4 dos 6 falha contra a implementação anterior. Este repo não tem corredor de testes.