- Shipped
- September 23, 2026 at 10:24 AM UTC
- Author
- Kamo
- Commit
- d4865f7
Two leftover debug-logging spots on the WebSocket path: - WebSocketConfig's inbound channel interceptor logged every STOMP frame at INFO, including accessor.toMap() (the CONNECT frame's headers carry the member's rights array) and the raw payload (chat message bodies) - on every frame the broker relays. - WebSocketLoggingFilter logged every header of every /ws/** request at INFO, including Cookie (the *** session token), on the SockJS handshake and polling paths every tab hits. Both are now at most a DEBUG one-liner: command/destination/session for a STOMP frame, method/path/status for an HTTP request - never headers, never a payload, never a cookie. WebSocketConfig's beforeHandshake/afterHandshake (which also dumped request.getHeaders(), same problem, same file) got the same treatment. The STOMP destination authorization block (SUBSCRIBE/SEND guarding via StompDestinationAuthz) is untouched - not a logging concern, and another agent's recent fix lives right next to it. Also dropped the banner/emoji startup logging in configureMessageBroker and registerStompEndpoints (one-time, not a security issue, but the same files and worth doing while touching them) down to one line each. Covered by WebSocketConfigFrameLoggingTest and WebSocketLoggingFilterTest, which attach a Logback ListAppender at Level.ALL and assert no captured event's formatted message contains a marker value planted in the frame's payload, its native "rights" header, or the request's Cookie/query string - mutation-checked against the old logging (reverting it turns 4 of the 6 assertions red, including both the rights-header and Cookie leaks).