Create solid documentation on Websocket Authentication

Currently, the WebSocket / stomp security reference documentation contains two unhelpful lines about authenticating a user on a WebSocket. They basically seems to suggest spring-websocket can only be used in a website where a user is already authenticated.

AFAIK, this is not correct given the advances in spring-session and spring-security.

I've found that finding out how to authenticate a user over spring-websocket takes you through a web of examples and gists representing various versions of spring-security, spring-session and spring-websocket, stackoverflow questions and Github issues.

It's an absolute maze. And it's something you want to do right, since if you screw up, you're opening yourself up to all sorts of disasters.

I would recommend writing documentation that explains how to authenticate, authorize, reconnect and maintain secure (csrf etc) a websocket based connection assuming a server that serves both mobile devices and browsers, discussing both server and client.

The assumption that websocket is the primary channel for mobile app communication needs to be at the basis of our understanding of how this will be used most. It's not just about a website with a chat pane.

I realize that the client side is basically outside of the scope of the core documentation. So, this could be placed in guides perhaps.

What I find missing currently:

• How the session token works conceptually.
• Not clear how to pass a session id token to authenticate a user on a websocket. i.e. how to (re-)activate a websocket session on a client
• How to reconnect a websocket after a connection was lost (server down, no 3g etc)
• How to configure front end webservers like nginx to properly process requests. The assumption is direct connection to Tomcat, which is never a production reality
• How to implement csrf
• What to expect in the connection flow in terms of headers and appropriate values, 101 upgrades etc. This is not clear and would help with helping newbies (like me) figure it out
• [...]

It's not entire clear if this is the right place for this issue since this concern overlaps spring-session, spring-security and spring-websocket.