Hi,
We have a Spring application with a SockJS / STOMP SimpleMessageBroker setup. User authentification happens through a JWT token passed in a STOMP CONNECT message header.
Everything is working as desired except we would like to close the broker sessions for the users with an expired JWT token. So users are not able to receive messages after their authentication expired.
To do so, I wanted to have a scheduled task that would inspect all the open sessions principals to check if they are expired, and send a DISCONNECT message when necessary.
However I've not been able to find a way to access the Principal object for the open sessions (seems to be stored in SimpleBrokerMessageHandler.SessionInfo).
Am I missing something or is this not currently possible?
Comment From: rstoyanchev
@bgK there is a SimpUserRegistry bean with the name "userRegistry" that you can use to get the currently connected users. Have you tried that?
Comment From: bgK
Hi,
Thank you for your answer. Indeed, I can get the list of connected users and their associated sessions through the SimpUserRegistry. However the returned SimpUser and SimpSession interfaces don't allow to retrieve the security Principal where the authentication information is stored. The actual object instances are static private classes and don't have the principal either, so casting does not seem to be an option.
Comment From: rstoyanchev
Yes we only expose the username and session id. Do you have a way to look up the authentication info from that? It's the only option currently. The SessionInfo that's in SimpleBrokerMessageHandler is for internal use to manage heartbeats.
Comment From: bgK
Hi,
Yes, I could create my own store using a ChannelInterceptor to be able to lookup Principals from session id. I was kind of hoping I would not have to do that so the various stores don't get out of sync, but that definitely possible.
Comment From: rstoyanchev
We can store and expose the Principal from SimpUser when it is available. This would work mainly for a local registry and would not with a multi-server registry where user registry content is exchanged.