Spring 4 STOMP over Websockets- How to setup login and passcode properly

Question

I'm playing around with Spring 4 Stomp over Websockets. Now I'm trying to put login and password in my configuration.

@Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        //registry.enableSimpleBroker("/queue/", "/topic/");
        //Enable MQ
        StompBrokerRelayRegistration relay=registry.enableStompBrokerRelay("/queue/", "/topic/");
        relay.setSystemLogin("login");
        relay.setSystemPasscode("passcode");
        //relay.setClientLogin("login");
        //relay.setClientPasscode("passcode");
        registry.setApplicationDestinationPrefixes("/app");

    }

But then when I try to connect with different login and passcode, I can still connect. Here's my javascript.

$scope.initSockets = function() {
        $scope.socket.client = new SockJS('/Html5GameApp');
        $scope.socket.stomp = Stomp.over($scope.socket.client);
        $scope.socket.stomp.connect("sample","sample",function(frame) {
        console.log('Connected: ' + frame);
        $scope.socket.stomp.subscribe("/queue/stomp.data", $scope.liveGameData);
        });
        $scope.socket.client.onclose = $scope.reconnect;    
    };

Am I doing wrong with my configuration?How will I setup it properly.Thanks

Answer 1

Your application is made of 3 "systems" or "actors" in this scenario:

• the browsers
• the Spring application
• the broker (e.g. RabbitMQ)

If you take a look at StompBrokerRelayRegistration's javadoc, you'll see that:

• system credentials are for the shared "system" connection and are used to send messages to the STOMP broker from within the application, i.e. messages not associated with a specific client session (e.g. REST/HTTP request handling method).
• client credentials are used when creating connections to the STOMP broker on behalf of connected clients.

If you're actually trying to enforce access security in your application, you could take a look at the portfolio sample and its security config. In a nutshell, security is enforced during the HTTP Upgrade phase in this example.