Co nie działało
RedactingFormatter w Monologu ukrywa wartości pod wrażliwymi kluczami, takimi jak password. Robi to na dwa sposoby: zamienia wartość klucza w kontekście na maskę, a potem przeszukuje gotowy tekst logu i usuwa z niego oryginalne sekrety. To drugie przejście łapie kopie, które przeciekły innymi drogami, na przykład przez PsrLogMessageProcessor, który wstawia wartości z kontekstu do treści komunikatu.
Przejście działa tylko dla sekretów, które formatter wcześniej zebrał. A metoda zbierająca przyjmowała jedynie teksty. Gdy pod kluczem password leżała tablica, nic z niej nie trafiało na listę sekretów. Wywołanie:
kończyło się poprawnie zamaskowanym kontekstem i hasłem zapisanym otwartym tekstem w treści komunikatu, bo procesor zakodował tablicę do JSON i wstawił ją w miejsce {password}.
Co zmieniliśmy
Doszła mała metoda pomocnicza collectSensitiveValue(), która przechodzi po wartości spod wrażliwego klucza i zbiera każdy tekst, jaki w niej znajdzie, na dowolnej głębokości. Respektuje ten sam limit głębokości MAX_DEPTH, którego klasa używa już przy strukturach odwołujących się do samych siebie.
Jak to sprawdziliśmy
Nowy test przepuszcza rekord przez PsrLogMessageProcessor, a potem przez RedactingFormatter, i sprawdza, że sekret zagnieżdżony w tablicy nie występuje w wyniku, a w jego miejscu jest [REDACTED].
Efekt
Zmianę scalił autor biblioteki 9 września 2026. Logi z aplikacji, które przekazują do Monologa tablice z danymi formularzy, nie zdradzają już haseł przez treść komunikatu.
