- Navios
- 22 de agosto de 2026 às 21:03 UTC
- Autor
- kamo
- Enviar
- 83c2790
Uma carga de / mostrou uma explosão de 401/403 antes da sessão estabelecida — user-info, ui-preferences, by-department, chat/unread, timezone/effective e Os bilhetes/conte tudo a falhar juntos, depois tudo a funcionar. Lê- se Como uma corrida de primeira pintura na página inicial. Não é um, e a sessão não é tarde: dois /api/user-info chamadas 22ms apart carregaram um token 128-char e nenhum token em todos os casos, respectivamente. São duas páginas diferentes. /validate e /logout não têm layout de sua próprio, então o layout root monta toda a pilha autenticada do provedor sobre eles — contra uma sessão que por construção ainda não existe na página cujo trabalho é criá-lo, e foi simplesmente destruído no outro. Cada um dos sete "sem identificação de sessão" estoura na janela de log de um pod em segundos de uma validação OTK ou um logout, e nenhum em qualquer outro lugar. O 403 em bilhetes/contagem pendente é a mesma causa, não um direito em falta: MediaService responde a um pedido sem sessão 403 onde o SecurityService responde 401. O ruído era a metade visível. Um splash de login também estava abrindo um STOMP ligação, subscrevendo a presença, armando o catálogo de sons e o Notificação e contagem de sondagens — a ser demolida um segundo mais tarde por window.location.href. Assim, a pilha se move para AuthedChrome, que torna a página nua em um caminho pré-sessão. Ambos são um fixo, full-viewport LoadingScreen, então nenhum Queria a caixa de conteúdo de navegação. SessionBootstrap é içada ABOVE o gate: /validate escreve o token cujo leitor instala, por isso tem que ser montado na única página que o shell não é. Captura de ligação profunda, carregamento O gerente e o favicon temáticos já estavam acima dele e ficaram lá. A lista de caminhos era de três cópias antes disso — um EXEMPT PATHS privado em cada deus componente de modo e uma verificação em linha no useUserInfo's 401 handler, que casos especiais os mesmos dois caminhos para um 401 esperado não saltar um visitante para /logout de /logout. Uma autoridade agora, portanto, uma terceira página pré-sessão não pode ser adicionado a dois dos três. Correspondência exata, não prefixo: proxy.ts deliberadamente trata /validate/* como público, e a porta do cliente não deve se ampliar por conta própria. Também aqui, ambos encontrados ao rastrear o mesmo console: - sessões/suporte/auto-aberto 404'd porque o proxy hop nunca foi escrito. O MediaService serviu-o o tempo todo; só faltava a rota seguinte, e AutoOpenUnreadSupportChats engole uma resposta não-ok por design, então suporte conversas atribuídas enquanto um agente estava fora silenciosamente nunca abriu. - Favicon.ico 404'd duas vezes por carga. O verdadeiro favicon é temático e injetado em runtime; nada respondeu à sonda padrão do navegador. Adicionado ao público/e NÃO app/, deliberadamente: um app/favicon.ico faz Next emitir um <link rel=icon> à frente dos links temáticos do DynamicMetaLoader, e TabAttention muda o PRIMEIRO ícone link que ele encontra — ele iria emblemar o errado eo crachá iria desaparecer. Em público/ é servido sem tag, e TabAttention próprio /favicon.ico Retrocesso agora resolve em vez de não carregar. Verificado: npx tsc -- noEmit, teste npm (2706 testes, 187 arquivos), compilação de execução npm.