@@ -37697,10 +37697,10 @@ Or if connecting via WebSocket (without SockJS):
37697
37697
}
37698
37698
----
37699
37699
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.
37701
37701
Even if it did, they would be ignored, or rather overridden, on the server side. See the
37702
37702
sections <<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.
37704
37704
37705
37705
37706
37706
[[websocket-stomp-message-flow]]
@@ -38042,20 +38042,48 @@ and may be useful for example in a cloud environment where the actual host to wh
38042
38042
the TCP connection is established is different from the host providing the
38043
38043
cloud-based STOMP service.
38044
38044
38045
- [[websocket-stomp-handle-user ]]
38046
- ==== Authentication and User Destinations
38045
+ [[websocket-stomp-authentication ]]
38046
+ ==== Authentication
38047
38047
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.
38049
38051
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.
38053
38058
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.
38059
38087
38060
38088
Spring's STOMP support recognizes destinations prefixed with `/user/`.
38061
38089
For example, a client can subscribe to destination `/user/position-updates`.
0 commit comments