Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Motivo: Spring-security está integrado.Interceptou a solicitação do websocket e não gerou logs (porque o nível geral de log relacionado ao Spring é avisado. Há muitos logs no modo de depuração)

Então você pode modificar o nível de registro de ressaca para visualizar os registros

# 日志配置
logging:
  level:
    com.cas.wict: debug
    org.springframework: warn
    org.springframework.web: debug
    io.undertow: debug

Saída de registro de chaves

2024-07-11 10:15:43.292 [XNIO-1 task-1] DEBUG io.undertow.request.security
 - Attempting to authenticate /ws, authentication required: false
2024-07-11 10:15:43.293 [XNIO-1 task-1] DEBUG io.undertow.request.security
 - Authentication outcome was NOT_ATTEMPTED with method io.undertow.security.impl.CachedAuthenticatedSessionMechanism@7fedbc60 for /ws
2024-07-11 10:15:43.293 [XNIO-1 task-1] DEBUG io.undertow.request.security
 - Authentication result was ATTEMPTED for /ws

Descobri que a segurança pode ter interceptado o caminho da solicitação ws (por que foi interceptado, acho que embora o ws tenha sido escrito, ainda era http quando foi iniciado e foi atualizado do plano de fundo para o websocket)

Solução: deixe de lado a verificação e escreva um filtro separado para verificar solicitações ws

Por que era possível conectar-se usando netty-websocket antes? Foi porque o netty não usava a cadeia de filtros de segurança de mola.