- Navios
- 23 de setembro de 2026 às 10:24 UTC
- Autor
- Kamo
- Enviar
- d4865f7
Dois pontos restantes de depuração no caminho WebSocket: - WebSocketConfig interceptor de canal de entrada registrou cada quadro STOMP em INFO, incluindo o acessor.toMap() (os cabeçalhos do quadro CONNECT carregam o array de direitos dos membros) e a carga útil bruta (corpos de mensagens de bate-papo) - on Todos os relés dos corretores. - WebSocketLogging Filtrar cada cabeçalho de cada pedido /ws/** em INFO, incluindo Cookie (o símbolo de sessão ***), no aperto de mão do SockJS e a sondar os caminhos de cada tabulação. Ambos são agora, no máximo, um DEBUG uma linha: comando/destino/sessão para um STOMP frame, method/path/status para uma requisição HTTP - nunca cabeçalhos, nunca Uma carga, nunca uma bolacha. WebSocketConfig's antesHandshake/afterHandshake (que também descartou request.getHeaders(), mesmo problema, mesmo arquivo) tem o mesmo tratamento. O bloco de autorização de destino STOMP (SUBSCRIBE/SEND guarda via StompDestinationAuthz) é intocado - não é uma preocupação madeireira, e a recente reparação de outro agente vive mesmo ao lado dela. Também deixou cair o registro de inicialização banner/emoji no configureMessageBroker e registerStompEndpoints (uma vez, não um problema de segurança, mas os mesmos arquivos e vale a pena fazer ao tocá-los) até uma linha cada. Coberto por WebSocketConfigFrameLoggingTest e WebSocketLogging FilterTest, que anexam uma Lista de LogbackAppender ao nível. ALL e afirmar não capturado a mensagem formatada do evento contém um valor de marcador plantado no quadro payload, seu cabeçalho nativo "direitos", ou a string Cookie/query da solicitação - Mutação verificada com o registro antigo (revertendo-o gira 4 dos 6 asserções vermelho, incluindo tanto o cabeçalho de direitos e vazamentos de Cookie).