Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simp allows glob subscription to receive another user messages [SPR-14813] #19379

Closed
spring-projects-issues opened this issue Oct 14, 2016 · 1 comment
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@spring-projects-issues
Copy link
Collaborator

Yury Altukhou opened SPR-14813 and commented

Messages sent from server to user queue(from methods with @SendToUser) will also be sent to clients that subscribed with glob pattern '/queue/*'

Setup is: webmvc+(stomp over sockjs).
In attached tests:

  1. connect 2 stomp clients
  2. subscribe client 1 to '/user/queue/*'
  3. subscribe client 2 to '/queue/*'
  4. send message from client 1 to 'echo' service ,that has @SendToUser('/queue/echo') annotation
  5. expect client 1 to get two messages(connect reply,echo message)
  6. expect client 2 to get one message (connect reply)
    Fail: client 2 got two messages, second one with 'destination:/user/queue/echo'

Affects: 4.3.2, 4.3.3

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Thanks for the sample. Note that as of 4.2 we provide a STOMP client that can be used with the SockJsClient.

Regarding the issue, the simple broker does have any special semantics for /topic (pub-sub) vs /queue (point-to-point) as message brokers do. Those are mere conventions that mimic the semantics but there is nothing to enforce them. Along the same lines for user destination, it's merely a convention that allows a user to subscribe to a unique queue then another user to send messages targeting the user's queue. We don't actively enforce that no other user can receive those messages.

Spring Security provides support for authorizing incoming messages so you can do things like allow subscriptions to /user/*, or disallow subscriptions to /queue/*. You can also install your own interceptor but Spring Security will give you more complete support.

@spring-projects-issues spring-projects-issues added type: bug A general bug status: declined A suggestion or change that we don't feel we should currently apply in: messaging Issues in messaging modules (jms, messaging) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug A general bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

2 participants