CODEWITHSUNDEEP
javaspringwebsocketstomp
SatA
SatA

Reputation: 567

Communication relationship when using SimpleBrokerMessageHandler - STOMP Spring

Cant seem to find an answer for this question and not enough documentation about SimpleBrokerMessageHandler.

I went along this example: https://gerrydevstory.com/2014/03/04/stock-ticker-demo-webapp-using-spring-4-websocket/

and it seems that if the client sends a message to the topic, all other clients subscribed to that topic will receive that message. As if the default relationship of the topic is many-to-many.

I would expect that the relationship would be one-to-many, meaning one server to many clients and not many clients to many clients and the server.

This behavior suggests a security/authenticity problem - following the example in the link above, a client could send a fake stock price to everyone else, impersonating to the server.

I would also expect that if this is the behavior, then it could somehow be overridden or changed somewhere in the configuration of spring websockets and stomp but I just can't find enough information on this anywhere.

So the questions are:

  1. Is the default behavior really many-to-many for the SimpleBrokerMessageHandler?
  2. Am I not correctly understanding the meaning of topic?
  3. Can this behavior be somehow changed or controlled?
  4. If not, would ActiveMQ or RabbitMQ or any other third-party broker be of any help for my needs (implementing a one-to-many scheme)? And how?

Upvotes: 2

Views: 938

Answers (1)

Sergi Almar
Sergi Almar

Reputation: 8414

Destinations with /topic prefix are usually broker destinations, and as you correctly said, anyone can send messages to such destinations and those will be received by all subscribers (messages are actually forwarded to the broker).This will happen with both the simple broker and the broker relay (using any full-blown STOMP broker like RabbitMQ or ActiveMQ).

However, Spring Security 4 (in M2 currently), adds websocket security support so you can restrict sending messages or subscribing to destinations (see JIRA SEC-2713). If that's not enough you could implement your own ChannelInterceptor and add it to the clientInboundChannel so you can process the message and discard it according to your logic.

Upvotes: 2

Related Questions