I will show you how to abuse both of them :) Solution using User Principal It turns out there are two candidates: getUserPrincipal() and getRequestParameterMap(). Second, find some properties that exist in both the WebSocket Session and HttpServletRequest or HttpSession. It also gives you a chance to create a session if it doesn't already exist (although in that case using an HTTP session at all seems dubious). This will give you access to the HttpServletRequest and HttpSession. There are two key tricks.įirst, use a filter with the same path as the WebSocket. I've developed two solutions, which I've verified work correctly when tested against a multithreaded client. In both cases I observed the incorrect session being associated with the endpoint instance.
To verify, I copied the code directly from the other answers and then tested it against a multithreaded client I wrote. You can check by printing out the map contents before modifying it within modifyHandshake(.). In practice some implementations (e.g., Glassfish) return the same Map instance for all calls to ServerEndpointConfig.getUserProperties() while others (e.g., Tomcat 8) don't.
The text of JSR 356 itself does not mention EndpointConfig.getUserProperties(), it is only in the JavaDoc, and nowhere does it seem to be specified what its exact relationship is to Session.getUserProperties(). More surprisingly the answer from Joakim Erdfelt also does not work reliably. Anyway you can easily see if an implementation is using the same instance by printing out its toString() from within modifyHandshake(.). While the docs state that "The implementation creates a new instance of the configurator per logical endpoint," the spec does not clearly define a "logical endpoint." Based on the context of all the places that phrase is used, it appears to mean the binding of a class, configurator, path, and other options, i.e., a ServerEndpointConfig, which is clearly shared. The answer from Martin Andersson is not correct because the same instance of ServerEndpointConfig.Configurator is used for every connection, hence a race condition exists. I've omitted null and index bounds checks for brevity. My answer will show how to get the HttpSession or individual properties. It's unclear whether you're wanting the HttpServletRequest, the HttpSession, or properties out of the HttpSession. import java.io.JSR-356 WebSockets with Tomcat-How to limit connections within single IP address? This works the opposite way if compared with HTTP requests, where the client has to request each time it expects a reply from the server. This socket demonstrates how the client has to listen to messages from the server without further sending any information to the server. The below server socket accepts the connection via a blank message and sends the message back to the client after repeated intervals. So ws:// is just like and wss:// uses same SSL certificate used by Server Socket After the successful handshake connection, only the duplex connection is established. The client needs to make its regular HTTP request (handshake) to initiate websocket connection.
Websockets are designed to work like TCP, providing full duplex communication but they are not TCP. We will demonstrate how to build websockets using Tomcat 8 and HTML5 websocket API.