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.
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... this seems like something that Spring would already have created in the app context.
Does such a bean/service exist already?
Some background:
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.
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.
All thoughts and suggestions appreciated.
EDIT
Indeed, Spring's SubProtocolWebSocketHandler class maintains a sessionId to WebSocketSession map, but all access to that map is private.
EDIT
There is support for tracking Users, Sessions, and Subscriptions at the STOMP level. This was added in version 4.2 and isn't documented in the chapter on WebSockets. (It's mentioned as a bullet point under "what's new".)
There is a SimpUserRegistry interface which provides the ability to get a user by name or a set of all users. These are SimpUser instances, which expose access to that user's sessions as a SimpSession either by a session id or as a set of all sessions for that user. From that you can obtain a set of SimpSubscription instances that represent STOMP subscriptions.
Per the javadoc, this should also work in a clustered (relay broker) environment.
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.
See the last section of authentication under web sockets:
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.
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.
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.
Related
Roughly speaking a HTTP SESSION is a kind of secret that the server sends to the client (ex browser) after user's credentials is checked. This secret is passed trough all subsequents HTTP requests and will identify the user. This is important because HTTP are stateless - source.
Now I have a scenario where there is a communication between a machine and a MQTT broker inside the AWS-IoT core. The machine displays some screens. The first screen is the login and password.
The idea here is that after the first screen, IF the credentials are validated, the server should generate a "session" and we should send this "session" across the screen pages. The machine should send this "SESSION" in all subsequent messages and the server must to validate this string before any action. This is a request created by an electrical engineering team.
Me, in the software development side it seems that make no sense since all machines to be connected in the AWS IoT-Core broker (MQTT) must to use a certificate - with is the validation already.
Beside of that, the MQTT broker offers the SESSION persistence capabilities. I know that the SESSIONs (QoS 0/1) in the broker side are related to idea of confidence of delivery and reception of a message.
That being said is it possible to use session persistence in MQTT to behavior like a sessions in HTTP in order to identify users across screens in devices? If yes how?
No, HTTP Session concept is not in any way similar to the MQTT session. The only thing held in a MQTT clients session is the list of subscribed topics, a HTTP session can hold arbitrary data.
Also MQTT messages hold NO information about the user or even the client that published the message when it is delivered to the subscriber, the ONLY information present is the message payload and the topic it was published to.
While MQTTv5 adds the option to include more metadata, trying to add the concept of users sessions is like trying to make a square peg fit in round hole.
If you want to implement something as part of the message payload then that is entirely up to you, but it is nothing to do with the transport protocol.
I am new to Spring framework, now I chose it for a new project.
The project is actually an online consulting application. when a customer chooses to query by open page window, A consulting engineer will be assigned to him(many to one). to sum up, this app requires the following considerations.
1- anonymity connections for customer and authentication for consulting engineers.
2- one engineer can serve several customers at a time.
3- the way to assign customer could be configured.
4- WebSocket session should remain open while HTTP session expired.
so I have two questions:
for 1-3 items, I am not sure if I should choose STOMP or plain WebSocket in Spring. it seems STOMP is more advanced but more likely to fit a general messaging requirement (topics, subscriptions ... etc). WebSocket in another hand is simpler and more flexible. I wonder which one is better in this consulting application?
for point 4, session expired. google result suggests spring-session. but I can only found its tutorial about integration spring-session with STOMP. if WebSocket is the better choice, how can I integrate spring-session with Plain WebSocket?
Thanks
When you talk about websocket you have to have in mind that it is a simple and "raw" communication protocol without many defined message controls. If you choose to use plain websocket you should be able to authenticate using basic authentication [1]. In this case, your websocket connection, once opened, will stay open and working indefinitely.
But it's also up to you to control the message flow, deciding how to specify the target for each message. That's where STOMP should help you.
Using STOMP you could define "channels" to which customers and consulting enginners would "subscribe" to and begin communication. And you could also send private messages using the "Principal" from an authenticated Spring Security session.
So, answering your points:
1- anonymity connections for customer and authentication for
consulting engineers.
It is possible to define multiple endpoints within Spring Websocket configuration [2]. You could try to request authentication with only one of the endpoints using a implementation of ChannelInterceptorAdapter.
2- one engineer can serve several customers at a time.
Using the definition of channels, with the help of STOMP, you could subscribe the enginner in multiple channels, each for one customer... Or use private messages between them.
3- the way to assign customer could be configured.
I'm not sure what you meant... But it should be easy to assign a customer to a "channel".
4- WebSocket session should remain open while HTTP session expired.
The HTTP session is only used in the initial process, to connect to the websocket. After that the websocket will remain open or, if you use SockJS for fallback, the HTTP session will be constantly renewed.
I have coded an example of websocket server and client using Spring API. It's not exactly what you need, but I think it'll give a good idea.
Java EE 7 allows you to create new endpoints very easily through annotations. However, I was wondering is having multiple endpoints one to handle each message type a good idea or should I have just one endpoint facade for everything?
I am leaning towards having one single end-point facade based on the theory that each endpoint creates a new socket connection to the client. However, that theory could be incorrect and Web Socket may be implemented so that it will use just one TCP/IP socket connection regardless of how many web socket end points are connected so long as they connect to the same host:port.
I am asking specifically for Java EE 7, as there may be other web socket server implementations that may do things differently.
Just noticed an ambiguity on my question re: message types. When I say message types I meant different kinds of application messages not native message types such as "binary" or "text". As such I marked #PavelBucek answer as the accepted one.
However, I did try an experiment with Glassfish and having two end points. My suspicions were correct and that there is a TCP connection established per connected endpoint. This would cause more load on the server side if there is more than one websocket endpoint being used on a single page.
As such I concluded that there should be only one endpoint to handle the application messages provided that everything is a single native type.
This would mean that the application needs to do the dispatching rather than relying on some higher level API to do it for us.
The only valid answer here is the latter option - having multiple endpoints.
See WebSocket spec chaper 2.1.3:
The API limits the registration of MessageHandlers per Session to be one MessageHandler per native websocket message type. [WSC 2.1.3-1] In other words, the developer can only register at most one Mes- sageHandler for incoming text messages, one MessageHandler for incoming binary messages, and one MessageHandler for incoming pong messages. The websocket implementation must generate an error if this restriction is violated [WSC 2.1.3-2].
As for using or not using multiple TCP connections - AFAIK currently there will be new connection for every client and there is no easy way how you can force anything else. WebSocket multiplexing should solve it, but I don't think any WebSocket API implementation support it (I might be wrong..)
I'm designing a system where one server must send messages to lots of independent clients. The clients doesn't know about each other and should not be able to consume, peek or in any other way acquire knowledge about each others messages.
I therefore wonder if JMS / ActiveMq have the ability to control which clients get which messages?
I want all the clients to connect to the same JSM provider (the 'destination') and consume only messages meant for them. This would be a simple setup from the servers point of view.
An alternative would be to acquire webservice endpoints from all the clients and perform ws-calls every time the server have a message for a client. I think this alternative sound 'wrong' as I think ws calls are bloated. There is a great overhead for each ws call, and this server would have to make 1000's of call each day. In my opinion this would be suboptimal for the server...
Short answer: Use Message selector.
Detail answer:
The question doesn't mention about how conversation is initiated. So here my answers for both scenarios.
a) If client initiates the conversation (i.e. Client sends a message to server and waiting for a reply).
This is a request/reply scenario. Messaging/JMS is a decoupled communication system. But request/reply is a common pattern in JMS. It can be implemented using correlation pattern.
A unique identifier(correlation id) is sent part of the request message.
Server receives the message and sets the correlation id in the reply message.
Client uses Message selector to receive the message with the correct correlation id.
b) If server initiates the conversation (i.e. Server sends messages to the clients without client request).
In this case, similar approach can be used.
A fixed client id is assigned to each client.
Server maintains all client ids and sets client id of the recipient as correlation id of the message.
Client uses Message selector to receive the message which has correlation id equals to its client id.
Update about confidentiality.
Following info extracted from this link useful for you to understand JMS security.
JMS does not specify a security
contract or an API for controlling
message confidentiality and integrity.
Security is considered to be a
JMS-provider-specific feature. It is
controlled by a System Administrator
rather than implemented
programmatically or by the J2EE server
runtime.
Two major features of JMS security are Authentication and Authorization. According to my knowledge, JMS security for client access is focusing on protecting the JMS destinations (not the individual messages). As long as a client has access to a destination, the security role assigned to the client is applicable for all the messages belongs to the destination.
Based on this,
Solution 1: If the client code is controlled by a trusted party.
Follow my solutions in my original answer.
This will make sure the message is delivered to the right person. But will not protect anything if the client code is purposely modified to receive all messages.
Solution 2: Assign private destination and user account to each client and configure security such that user account of a client can access only its destination.
Note: Found a link about "Restrictions for message selectors to provide message level authorization". But I think it is a vendor specific custom feature.
Hope this will be helpful.
I have a Java application which I make available via RESTful web services. I want to create a mechanism so clients can register for notifications of events. The rub is that there is no guarantee that the client programs will be Java programs and hence I won't be able to use JMS for this (i.e. if every client was a Java app then we could allow the clients to subscribe to a JMS topic and listen there for notification messages).
The use case is roughly as follows:
A client registers itself with my server application, via a RESTful web service call, indicating that it is interested in getting a notification message anytime a specific object is updated.
When the object of interest is updated then my server application needs to put out a notification to all clients who are interested in being notified of this event.
As I mentioned above I know how I would do this if all clients were Java apps -- set up a topic that clients can listen to for notification messages. However I can't use that approach since it's likely that many clients will not be able to listen to a JMS topic for notification messages.
Can anyone here enlighten me as to how this problem is typically solved? What mechanism can I provide using a RESTful API?
I can think of four approaches:
A Twitter approach: You register the Client and then it calls back periodically with a GET to retrieve any notifications.
The Client describes how it wants to receive the notification when it makes the registration request. That way you could allow JMS for those that can handle it and fall back to email or similar for those that can't.
Take a URL during the registration request and POST back to each Client individually when you have a notification. Hardly Pub/Sub but the effect would be similar. Of course you'd be assuming that the Client was listening for these notifications and had implemented their Client according to your specs.
Buy IBM WebSphere MQ (MQSeries). Best IBM product ever. Not REST but it's great at multi-platform integration like this.
We have this problem and need low-latency asynchronous updates to relatively few listeners. Our two alternative solutions have been:
Polling: Hammer the list of resources you need with GET requests
Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.
In the response to the RESTful request, you could supply an individualized RESTful URL that the client can monitor for updates.
That is, you have one URL (/Signup.htm, say), that accepts the client's information (id if appropriate, id of object to monitor) and returns a customized url (/Monitor/XYZPDQ), where XYZPDQ is a UUID created for that particular client. The client can poll that customized URL at some interval, and it will receive a notification if the update occurs.
If you don't care about who the client is (and don't want to create so many UUIDs) you could just have separate RESTful URLs for each object that might want to be monitored, and the "signup" URL would just return the correct one.
As John Saunders says, you can't really do a more straightforward publish/subscribe via HTTP.
If polling is not acceptable I would consider using web-sockets (e.g. see here). Though to be honest I like the idea suggested by user189423 of multipart content-type or chunked transfer-encoding as well.