client-side stomp authentication headers are passed to the message broker [SPR-11154]

[spring-projects-issues]

zyro opened SPR-11154 and commented

environment: using rabbitmq with its stomp plugin and default configuration as message broker impl.

if i understand correctly how the stomp client registration currently works, it should never be necessary that a (web-) user sends stomp authentication headers ("login"/"passcode") in a websocket message?

the behavior that i am currently seeing is:

1. wrong/dummy credentials: [BAD CONNECT] reply from rabbitmq
2. empty strings as login/passcode: some header format error from StompDecoder
3. no credentials (i.e. empty js-object as stompClient connect headers): works

--> even if #3 works, that does mean a client is able to "knock" at the message brokers stomp authentication (#1).
--> also, i guess #3 does just work because the rabbitmq default configuration defines a "default_user" (guest/guest) that is used if login/passcode are omitted.
--> shouldnt the configured StompBrokerRelayRegistration.applicationLogin and StompBrokerRelayRegistration.applicationPasscode be used for a users CONNECT-frame as well?

---

Affects: 4.0 RC2

Issue Links:

• Don't forceably override client login and passcode on STOMP CONNECT [SPR-12722] #17319 Don't forceably override client login and passcode on STOMP CONNECT

Referenced from: commits 4e5e700

[spring-projects-issues]

Rossen Stoyanchev commented

Currently we have systemLogin/Password fields in the broker relay, which are used for the shared "system" connection used to send messages from the within the (server-side) application. We can add applicationLogin/Password properties and set them if client CONNECT frames don't already have such headers. Does that seem reasonable?

[spring-projects-issues]

zyro commented

applicationLogin/Passcode sounds good. but i would suggest that these settings do - if they are set - override the corresponding headers on a message incoming from a websocket client.

[spring-projects-issues]

Rossen Stoyanchev commented

See commit 4e5e70.