@@ -37697,10 +37697,10 @@ Or if connecting via WebSocket (without SockJS):
3769737697 }
3769837698----
3769937699
37700- Note that the stompClient above need does not specify a `login` and `passcode` headers.
37700+ Note that the stompClient above does not need to specify a `login` and `passcode` headers.
3770137701Even if it did, they would be ignored, or rather overridden, on the server side. See the
3770237702sections <<websocket-stomp-handle-broker-relay-configure>> and
37703- <<websocket-stomp-handle-user >> for more information on authentication.
37703+ <<websocket-stomp-authentication >> for more information on authentication.
3770437704
3770537705
3770637706[[websocket-stomp-message-flow]]
@@ -38042,20 +38042,48 @@ and may be useful for example in a cloud environment where the actual host to wh
3804238042the TCP connection is established is different from the host providing the
3804338043cloud-based STOMP service.
3804438044
38045- [[websocket-stomp-handle-user ]]
38046- ==== Authentication and User Destinations
38045+ [[websocket-stomp-authentication ]]
38046+ ==== Authentication
3804738047
38048- An application can also send messages targeting a specific user.
38048+ In a WebSocket-style application it is often useful to know who sent a message.
38049+ Therefore some form of authentication is needed to establish the user identity
38050+ and associate it with the current session.
3804938051
38050- To do so a user must first be authenticated. Although the STOMP `CONNECT` frame
38051- has authentication headers when used over WebSocket, it makes more sense to use
38052- the same HTTP-based authentication already used to secure the application.
38052+ Existing Web applications already use HTTP based authentication.
38053+ For example Spring Security can secure the HTTP URLs of the application as usual.
38054+ Since a WebSocket session begins with an HTTP handshake, that means URLs mapped
38055+ to STOMP/WebSocket are already automatically protected and require authentication.
38056+ Moreover the page that opens the WebSocket connection is itself likely protected
38057+ and so by the time of the actual handshake, the user should have been authenticated.
3805338058
38054- For example, an application can use Spring Security as usual to protect HTTP URLs,
38055- including paths to STOMP WebSocket endpoint(s). The authenticanted user, based
38056- on the value returned from `HttpServletRequest.getUserPrincipal()`, will be
38057- saved in the WebSocket session and subsequently added as a header named `user`
38058- to all incoming messages for that STOMP/WebSocket session.
38059+ When a WebSocket handshake is made and a new WebSocket session created,
38060+ Spring's WebSocket support automatically transfers the `java.security.Principal`
38061+ from the HTTP request to the WebSocket session. After that every message flowing
38062+ through the application on that WebSocket session is enriched with
38063+ the user information. It's present in the message as a header.
38064+ Controller methods can access the current user by adding a method argument of
38065+ type `javax.security.Principal`.
38066+
38067+ Note that even though the STOMP `CONNECT` frame has "login" and "passcode" headers
38068+ that can be used for authentication, Spring's STOMP WebSocket support ignores them
38069+ and currently expects users to have been authenticated already via HTTP.
38070+
38071+ In some cases it may be useful to assign an identity to WebSocket session even
38072+ when the user has not formally authenticated. For example a mobile app might
38073+ assign some identity to anonymous users, perhaps based on geographical location.
38074+ The do that currently, an application can sub-class `DefaultHandshakeHandler`
38075+ and override the `determineUser` method. The custom handshake handler can then
38076+ be plugged in (see examples in <<websocket-server-deployment>>).
38077+
38078+
38079+
38080+ [[websocket-stomp-user-destination]]
38081+ ==== User Destinations
38082+
38083+ An application can send messages targeting a specific user.
38084+ In order for a connected user to receive messages, they must be authenticated
38085+ so that their session is associated with a concrete user name.
38086+ See the previous section on information about authentication.
3805938087
3806038088Spring's STOMP support recognizes destinations prefixed with `/user/`.
3806138089For example, a client can subscribe to destination `/user/position-updates`.
0 commit comments