Description
Raman Gupta opened SPR-14690 and commented
There seems to be an inconsistency in the way Spring Messaging WebSocket is implemented and reality, when using token based authentication.
From the discussion on issue #17761 it is clear that Spring expects the authentication to be done during the HTTP message that establishes the web socket. This is fine for cookie-based auth, but when one is using a token, the token cannot be sent to the server in the headers, because SockJS does not support this (because browsers do not support it). See: sockjs/sockjs-client#196.
Now, one has two options: 1) send the token in a query parameter (which has some security issues), or 2) as suggested in #17761, configure a ChannelInterceptor on the "clientInboundChannel" and pass the token as a Stomp message header. Neither approach seems to be a complete solution.
The first approach, besides having security issues with server-side logging of the token and possible referral leaks, does not seem to work for SockJS fallbacks -- for fallbacks, the determineUser method to extract the user from the query parameter is never called.
The second approach works well up to a point: Spring Security sees the Principal set here and sets the security context properly (awesome!). However, the Principal is never set in the websocket session, and so it is not possible to send messages to a specific user, because Spring cannot tie the username to a session id.
Affects: 4.3.2
Issue Links:
- Better documentation on WebSockets and support for token based authentication [SPR-14380] #18953 Better documentation on WebSockets and support for token based authentication
- Improve web socket header support [SPR-13170] #17761 Improve web socket header support
1 votes, 5 watchers