|
对于最新稳定版本，请使用 Spring Framework 7.0.6！ |
身份验证
每个通过 WebSocket 的 STOMP 消息会话都始于一个 HTTP 请求。 该请求可能是升级到 WebSocket 的请求（即 WebSocket 握手）， 或者在使用 SockJS 回退机制的情况下，是一系列 SockJS HTTP 传输请求。
许多 Web 应用程序已经内置了身份验证和授权机制，用于保护 HTTP 请求。通常，用户通过 Spring Security 使用某种机制（例如登录页面、HTTP 基本身份验证或其他方式）进行身份验证。已认证用户的安全上下文会保存在 HTTP 会话中，并与同一基于 Cookie 的会话中的后续请求相关联。
因此，对于 WebSocket 握手请求或 SockJS HTTP 传输请求，通常已经可以通过 HttpServletRequest#getUserPrincipal() 获取到已认证的用户。Spring 会自动将该用户与为其创建的 WebSocket 或 SockJS 会话关联起来，并随后通过用户头（user header）将其与通过该会话传输的所有 STOMP 消息关联。
简而言之，一个典型的Web应用程序在安全性方面无需做任何超出其已有操作之外的事情。用户在HTTP请求级别通过一个安全上下文进行身份验证，该上下文通过基于Cookie的HTTP会话进行维护（随后与为该用户创建的WebSocket或SockJS会话相关联），并导致每个流经应用程序的Message都会被打上用户头信息。
STOMP 协议确实在 login 帧中包含 passcode 和 CONNECT 头部。
这些头部最初是为基于 TCP 的 STOMP 设计的，并且在该场景下是必需的。然而，对于基于 WebSocket 的 STOMP，Spring 默认会忽略 STOMP 协议层的认证头部，并假定用户已在 HTTP 传输层完成身份认证。
预期 WebSocket 或 SockJS 会话中已包含经过认证的用户信息。