Is there a Spring WebSocketSession repository?
<p>I'm building out a Spring 4.2 based, WebSocket + SockJS + STOMP server, and I'd like to be able to get a reference to the WebSocketSession instance using the ws sessionId.</p>

<p>I can create a session manager myself by adding a WebSocketHandlerDecorator that registers new WebSocketSession's as their connections are established (and de-register's on close), but...  <em>this seems like something that Spring would already have created in the app context.</em></p>

<p><strong>Does such a bean/service exist already?</strong></p>

<p>Some background:</p>

<p>My main use case is a security concern.  I am performing authorization on a per STOMP message basis, and an unauthorized message should result in the closure of the associated WS.  I can intercept the messages and perform authorization, but at the moment I can't get a reference to the WebSocketSession in order to close it.</p>

<p>Second use case; after a successful web socket connection is made, my protocol expects a STOMP CONNECT within X seconds, or again I need to close the underlying WS connection.  This one is slightly more interesting since it is asynchronous/timed and doesn't have any natural context like a message interceptor has.</p>

<p>All thoughts and suggestions appreciated.</p>

<hr>

<p><strong>EDIT</strong></p>

<p>Indeed, Spring's <a href="http://docs.spring.io/spring-framework/docs/4.2.5.RELEASE/javadoc-api/index.html?org/springframework/web/socket/server/support/WebSocketHttpRequestHandler.html" rel="noreferrer">SubProtocolWebSocketHandler</a> class maintains a sessionId to WebSocketSession map, but all access to that map is private.</p>

<p><strong>EDIT</strong></p>

<p>There is support for tracking Users, Sessions, and Subscriptions <strong>at the STOMP level</strong>.  This was added in version 4.2 and isn't documented in <a href="http://docs.spring.io/spring/docs/4.2.5.RELEASE/spring-framework-reference/htmlsingle/#websocket" rel="noreferrer">the chapter on WebSockets</a>.  (<em>It's mentioned as <a href="http://docs.spring.io/spring/docs/4.2.5.RELEASE/spring-framework-reference/htmlsingle/#_websocket_messaging_improvements_2" rel="noreferrer">a bullet point</a> under "what's new".</em>)</p>

<p>There is a <a href="http://docs.spring.io/spring-framework/docs/4.2.5.RELEASE/javadoc-api/org/springframework/messaging/simp/user/SimpUserRegistry.html" rel="noreferrer">SimpUserRegistry</a> interface which provides the ability to get a user by name or a set of all users.  These are <a href="http://docs.spring.io/spring-framework/docs/4.2.5.RELEASE/javadoc-api/org/springframework/messaging/simp/user/SimpUser.html" rel="noreferrer">SimpUser</a> instances, which expose access to that user's sessions as a <a href="http://docs.spring.io/spring-framework/docs/4.2.5.RELEASE/javadoc-api/org/springframework/messaging/simp/user/SimpSession.html" rel="noreferrer">SimpSession</a> either by a session id or as a set of all sessions for that user.  From that you can obtain a set of <a href="http://docs.spring.io/spring-framework/docs/4.2.5.RELEASE/javadoc-api/org/springframework/messaging/simp/user/SimpSubscription.html" rel="noreferrer">SimpSubscription</a> instances that represent STOMP subscriptions.</p>

<p>Per the javadoc, this should also work in a clustered (relay broker) environment.</p>

<p>Note for future readers, the SimpUserRegistry assumes that you've authenticated a user at the HTTP level, and that said user is defined by the request Principal.  If you find yourself with an empty user registry, even though you have good STOMP connections, then you may not be authenticating the way the code wants.</p>

<p>See the last section of <a href="http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#websocket-stomp-authentication" rel="noreferrer">authentication under web sockets</a>:</p>

<blockquote>
  <p>Note that even though the STOMP CONNECT frame has "login" and
  "passcode" headers that can be used for authentication, Spring’s STOMP
  WebSocket support ignores them and currently expects users to have
  been authenticated already via HTTP.</p>
</blockquote>

<hr>

<p>All of the above still preclude access the the underlying web socket session, with it's close() method.  I suspect my adoption on WebSocket's is a bit early, and that what I'm seeing is good support at the upper layer protocol (STOMP) level, but less fully fleshed out support for customization at the lower Web Socket layer.</p>

<p>I'm still looking for a way to affect the lower level Web Socket connection based on upper level activity, like non-authorized messages or failure to CONNECT after a TTL.</p>