- Verschifft
- 23. September 2026 um 10:24 UTC
- Autor
- Kamo
- Ausschuss
- d4865f7
Zwei übrig gebliebene Debug-Logging-Spots auf dem WebSocket-Pfad: - WebSocketConfigs eingehender Kanalabfangjäger protokollierte jeden STOMP-Rahmen bei INFO, inklusive accessor.toMap() (die Header des CONNECT-Rahmens tragen die Mitgliederrechte-Array) und die Roh-Nutzlast (Chat-Nachrichten-Körper) - auf jeder Rahmen der Broker-Reiter. - WebSocketLoggingFilter hat jede Header von jeder /ws/** Anfrage angemeldet unter INFO, einschließlich Cookie (das *** Sitzungszeichen), auf dem SockJS Handshake und Polling Pfade jeder Tab trifft. Beide sind jetzt höchstens ein DEBUG One-Liner: command/destination/Sitzung für einen STOMP Frame, Methode/Pfad/Status für eine HTTP-Anfrage - niemals Header, nie eine Nutzlast, niemals ein Cookie. WebSocketConfig's before Handshake/afterHandshake (die auch gedumpte request.getHeaders(), gleiche Problem, gleiche Datei) bekam die gleiche Behandlung. Der STOMP Zielautorisierungsblock (SUBSCRIBE/SEND) Bewachung über StompDestinationAuthz) ist unberührt - kein Holzeinschlag, und ein anderer Agent der jüngsten Fix lebt direkt daneben. Auch das Banner/Emoji Start-up Logging in configureMessageBroker und registerStompEndpoints (einmal, kein Sicherheitsproblem, aber die gleichen Dateien und es lohnt sich, sie zu berühren) bis auf eine Linie jeweils. Abgedeckt von WebSocketConfigFrameLoggingTest und WebSocketLoggingFilterTest, die einen Logback ListAppender bei Level.ALL anbringen und keine erfassten Die formatierte Nachricht der Veranstaltung enthält einen Markerwert, der im Rahmen gepflanzt ist Nutzlast, seine native "Rechte"-Header, oder die Anfrage Cookie / Query String - Mutation-geprüft gegen die alte Anmeldung (Umkehrung dreht sich 4 der 6 Behauptungen rot, einschließlich der Rechte-Header und Cookie Lecks).