StompSubProtocolHandler logs every exception, including failed authentication errors from spring-security-messaging, with error stack trace. This fills logs with garbage. It also allows simple DOS attacks by attempting unauthorized connection to websocket until the server disk is full.
Solution - allow authentication exceptions (for spring-security-messaging, it seems to be AccessDeniedException) to be returned to client as errors without logging anything.
Comment From: rstoyanchev
We could refine the logging, I presume you mean here. Those are errors from sending the message through the inbound channel, which does not include actually handling them, so it's mostly the channel interceptors which likely include some logging themselves.
One option would be to log only a message without a stacktrace at ERROR but include the stacktrace at DEBUG. Would that work?
Comment From: icokk
It would be an improvement, but the real solution would be to add a catch handler for failed authorization exceptions before the catch-all handler and inside only call handleError(session, ex, message); without logging anything.
For spring websocket security, the exception seems to be org.springframework.security.access.AccessDeniedException.
Comment From: icokk
Oh, I forgot: if you don't want to add a refeernce to spring-security-core just to catch the exception, you could perheps detect it by full class name or add a configuration option for users to decide which errors to handle without logging.
Comment From: jhoeller
We could only really make it configurable for custom exception classes, not refer to Spring Security exceptions there - not by reference and not by class name either.
@rstoyanchev a fine-tuning of our default logging, like the stacktrace only at debug level as you suggested, would be worth backporting to 5.2.x and 5.1.x as well.
Comment From: rstoyanchev
For 5.2 and 5.1, I've refined the logging along the lines I suggested earlier. For 5.3.1 I've taken it further by not logging at all at ERROR level for rejected CONNECT messages which are failures before the session is even established, likely authentication failures, and therefore handled a bit differently. In such cases, where errors can only come from interceptors, it could be reasonably expected that interceptors themselves should decide what is appropriate to log in case of a rejection.
Hopefully this works for you @icokk.
Comment From: icokk
It will work, thank you.