Skip to content

Commit 32852e0

Browse files
committed
Improve doc on authentication for stomp/websocket
1 parent b02bda9 commit 32852e0

File tree

1 file changed

+41
-13
lines changed

1 file changed

+41
-13
lines changed

src/asciidoc/index.adoc

Lines changed: 41 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -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.
3770137701
Even if it did, they would be ignored, or rather overridden, on the server side. See the
3770237702
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.
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
3804238042
the TCP connection is established is different from the host providing the
3804338043
cloud-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

3806038088
Spring's STOMP support recognizes destinations prefixed with `/user/`.
3806138089
For example, a client can subscribe to destination `/user/position-updates`.

0 commit comments

Comments
 (0)