驗證

每個基於 WebSocket 的 STOMP 訊息傳輸會話都始於一個 HTTP 請求。這可能是升級到 WebSocket 的請求（即 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 會話關聯），並導致使用者標頭被標記在流經應用程式的每個訊息上。

STOMP 協議在 CONNECT 框架上確實有 login 和 passcode 標頭。這些標頭最初是為基於 TCP 的 STOMP 設計和需要的。然而，對於基於 WebSocket 的 STOMP，預設情況下，Spring 會忽略 STOMP 協議層級的驗證標頭，並假設使用者已經在 HTTP 傳輸層級進行了身份驗證。預期 WebSocket 或 SockJS 會話包含已驗證的使用者。