认证

每个 STOMP over WebSocket 消息会话都始于一个 HTTP 请求。这可以是一个升级到 WebSockets 的请求（即 WebSocket 握手），或者，在 SockJS 回退的情况下，一系列 SockJS HTTP 传输请求。

许多 Web 应用程序已经有认证和授权机制来保护 HTTP 请求。通常，用户通过 Spring Security 使用某种机制（例如登录页面、HTTP 基本认证或其他方式）进行认证。已认证用户的安全上下文保存在 HTTP 会话中，并与同一基于 cookie 的会话中的后续请求相关联。

因此，对于 WebSocket 握手或 SockJS HTTP 传输请求，通常已经可以通过 HttpServletRequest#getUserPrincipal() 访问已认证的用户。Spring 会自动将该用户与为其创建的 WebSocket 或 SockJS 会话相关联，随后，通过用户头与所有通过该会话传输的 STOMP 消息相关联。

简而言之，一个典型的 Web 应用程序除了已经为安全所做的工作之外，不需要做任何额外的事情。用户在 HTTP 请求级别进行认证，其安全上下文通过基于 cookie 的 HTTP 会话维护（然后与为该用户创建的 WebSocket 或 SockJS 会话相关联），并导致在流经应用程序的每个 Message 上都打上用户头。

STOMP 协议在 CONNECT 帧上确实有 login 和 passcode 头。这些最初是为 STOMP over TCP 设计的，并且是必需的。然而，对于 STOMP over WebSocket，Spring 默认忽略 STOMP 协议级别的认证头，并假定用户已在 HTTP 传输级别进行认证。期望是 WebSocket 或 SockJS 会话包含已认证的用户。