SEC-3177: Ability to intercept/handle messages sent to forbidden STOMP queues

Alex (Migrated from SEC-3177) said:

If I enable websocket and message broker security and a client send a messages to a queue where he has no access the server logs a big error of this kind with the whole stack trace (internal to spring security):

2015-12-18 10:50:05.867 ERROR 24291 --- [nio-9090-exec-1] o.s.w.s.m.StompSubProtocolHandler        : Failed to send client message to application via MessageChannel in session 1. Sending STOMP ERROR to client.

org.springframework.messaging.MessageDeliveryException: Failed to send message to ExecutorSubscribableChannel[clientInboundChannel]; nested exception is org.springframework.security.access.AccessDeniedException: Accesso negato
        at org.springframework.messaging.support.AbstractMessageChannel.send(AbstractMessageChannel.java:127) ~[spring-messaging-4.2.4.RELEASE.jar:4.2.4.RELEASE]
        at org.springframework.messaging.support.AbstractMessageChannel.send(AbstractMessageChannel.java:104) ~[spring-messaging-4.2.4.RELEASE.jar:4.2.4.RELEASE]
        at org.springframework.web.socket.messaging.StompSubProtocolHandler.handleMessageFromClient(StompSubProtocolHandler.java:280) ~[spring-websocket-4.2.4.RELEASE.jar:4.2.4.RELEASE]
[...]

I don't want to log all this mess on the server, but I want to log that a certain user has tried this invalid operation, so a method to override this behaviour would be welcome.

If it already there is a way, I've not found how.

Start at StompSubProtocolHandler.handleMessageFromClient, the entry point shown in the stack trace, and trace how authorization failures from client messages are handled. Done means the behavior can be intercepted or customized so forbidden STOMP queue attempts can be logged without the full server stack trace; the issue does not name a test to run.