fix(rollbar): przestań zamazywać linie kodu w tracebackach

[mpasternak]

Problem

ROLLBAR_SCRUB_FIELDS zawiera "code" — dodane świadomie, dla kodu
autoryzacyjnego OAuth w POST do /o/token/. Kłopot w tym, że pyrollbar trzyma
pod tą samą nazwą linię kodu źródłowego każdej ramki tracebacku, a
ScrubRedactTransform dopasowuje ścieżkę klucza po sufiksie — więc jeden
wpis trafiał w oba naraz.

Od pyrollbara 1.4.0 skutek jest taki, że każdy traceback w produkcyjnym
Rollbarze ma wszystkie linie kodu zamazane na "****". Widać to gołym okiem
w danych — ten sam błąd SMTP, dwa wydania:

item	pyrollbar	frames[4].code
#379	1.3.0	sent = conn.send_messages([dict_to_email(message)])
#1554	1.4.0	****

We wszystkich dziesięciu ramkach. Każde śledztwo w Rollbarze zaczyna się więc
bez najważniejszej informacji.

Zreprodukowane też lokalnie, poza Django — sam transform na ręcznie zbudowanym
payloadzie:

ramka code : '***********'
POST  code : '**********'

Rozwiązanie

"code" znika z ROLLBAR_SCRUB_FIELDS, a zamazywanie przejmuje
ScrubKoduAutoryzacyjnego (bpp/rollbar_config.py) — podklasa
ScrubTransform, która patrzy na całą ścieżkę klucza i odpuszcza, gdy
prowadzi ona przez frames:

ścieżka klucza	co to jest	decyzja
("request", "POST", "code")	kod autoryzacyjny OAuth	zamaż
("body", "trace", "frames", 0, "code")	linia kodu źródłowego	zostaw

Transform wpinany jest w configure_rollbar(), a nie w settings.ROLLBAR, żeby
nie importować bpp.* na etapie ładowania ustawień. To bezpieczne i celowe:
configure_rollbar biegnie z AppConfig.ready(), czyli przed middlewarem
django-rollbar, a rollbar.init buduje łańcuch transformów tylko przy
pierwszym wywołaniu — gdyby ubiegł nas middleware, transform nigdy by nie
wszedł. Osobny test pilnuje tego okablowania.

Pozostałe pola wrażliwe (password, code_verifier, refresh_token…) zostają
na liście i są nadal zamazywane wszędzie, także w zmiennych lokalnych ramek.

Testy

Cztery nowe w src/bpp/tests/test_rollbar_config.py, TDD — test linii kodu
najpierw padał (assert '*******' == "autor_str = ..."):

• linia kodu w tracebacku nie jest zamazywana,
• kod autoryzacyjny OAuth w żądaniu nadal jest (druga strona kontraktu —
  bez tego poprawka byłaby regresją bezpieczeństwa),
• password w zmiennych lokalnych ramki nadal znika,
• configure_rollbar faktycznie przekazuje transform do rollbar.init.

Zweryfikowane mutacją kodu produkcyjnego — każda łapana:

mutacja	wynik
przywrócenie "code" na listę scrubowanych	1 failed
transform nie zamazujący nic	1 failed
transform zamazujący wszędzie (ignoruje ramki)	1 failed

Lokalnie: src/bpp/tests/ + src/django_bpp/tests/ — 2959 passed, 2 skipped.

Uwaga

Poprawka działa od następnego wydania — itemy już zebrane w Rollbarze pozostają
z zamazanym kodem.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NcAqeqyqBzNEkkVnhpHDaH

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35165582	Triggered	Generic Password	cb1dd53	src/bpp/tests/test_rollbar_config.py	View secret
35165582	Triggered	Generic Password	5221229	src/bpp/tests/test_rollbar_config.py	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[mpasternak]

⚠️ Pierwsza wersja tego PR-a otwierała trzy wycieki. Naprawione w 52212296c

Self-review bezpieczeństwa wykazał, że moja poprawka otwierała kanały wycieku
kodu autoryzacyjnego, które wcześniej były zamknięte. Wszystkie potwierdzone
empirycznie na prawdziwym łańcuchu transformów, nie z lektury.

1. ?code= w URL-ach przestawało być czyszczone — najgroźniejszy

Wbudowany ScrubUrlTransform dostaje params_to_scrub=SETTINGS["scrub_fields"]
(rollbar/__init__.py:579). Zdjęcie stamtąd "code" odbierało mu wiedzę o tym
parametrze — i to wszędzie, bo jego in_scrub_fields zwraca True dla
każdego stringa, nie tylko dla klucza url.

To nie było teoretyczne: /orcid/callback/ (src/orcid_integration/views.py)
przyjmuje kod autoryzacyjny w query stringu, a pyrollbar zapisuje pełny
request.build_absolute_uri(). Każdy 500 w tym widoku wysłałby aktywny kod ORCID
w czystej postaci — w request.url, w Referer i w zmiennych lokalnych.

2. frames[N].locals.code i .kwargs.code — dokładnie ten sekret, o który chodziło

Ścieżka zawiera frames, więc mój warunek ją pomijał. A w django-oauth-toolkit
code jest parametrem kilkunastu metod walidatora (validate_code,
save_authorization_code, invalidate_authorization_code…) — wyjątek
w którejkolwiek wystawia aktywny kod w zmiennych lokalnych. Czyli poprawka
zostawiała dziurę w tym samym scenariuszu, dla którego "code" w ogóle
trafiło na listę.

3. "frames" not in key dawało się obejść

request.POST.frames.code oraz custom.frames[0].code przechodziły nietknięte.

Naprawa

Wyjątek to teraz dokładna lista dwóch ścieżek, pod którymi pyrollbar trzyma
linię kodu, zamiast testu podciągu:

("body", "trace",       "frames", <int>,            "code")
("body", "trace_chain", <int>,    "frames", <int>,  "code")

Dopasowanie nazwy klucza wróciło do case-insensitive (bez tego POST.Code
wyciekało), plus własny ScrubUrlTransform znający code.

Dlaczego testy tego nie złapały — i co z tym zrobiłem

Bo rekonstruowały łańcuch transformów zamiast go użyć: składały ręcznie
[ScrubRedactTransform] + custom_transforms i pomijały ScrubUrlTransform.
Świeciły na zielono przy wyciekającym URL-u.

Testy jadą teraz prawdziwym rollbar.init(**ustawienia_rollbara()) +
rollbar._build_payload. 18 testów, z czego 9 sprawdza wyciek — POST, GET,
inna wielkość liter, kolizja klucza frames, locals, kwargs, request.url,
Referer, URL w zmiennej lokalnej.

Każda z czterech poprawek zweryfikowana mutacją:

cofnięta poprawka	ile testów pada
usunięcie własnego ScrubUrlTransform	4
powrót do "frames" not in key	3
brak case-insensitivity	1
"code" z powrotem na scrub_fields	2

Sprostowania — dwa moje twierdzenia były fałszywe

„Od pyrollbara 1.4.0" — nieprawda. 1.3.0 zachowuje się identycznie
(to samo _build_payload, te same priorytety, to samo suffix-matchowanie).
Prawdziwa przyczyna to commit 13ce70be3 z 2026-07-11, który dodał "code"
do ROLLBAR_SCRUB_FIELDS — potwierdzone przez git log -S. Różnica wersji
notifiera między itemami #379 i #1554 to korelacja, nie przyczyna: itemy
rozdziela ta data, a nie upgrade biblioteki. Poprawione w docstringu, opisie
i newsfragmencie.

Komentarz przy ROLLBAR_SCRUB_FIELDS twierdził „dopasowuje po DOKŁADNEJ
nazwie klucza, NIE po sufiksie". To była nieprawda od początku
(build_key_matcher(..., type="suffix")) — i to właśnie ona uśpiła czujność
przy dodawaniu "code". Poprawiony, z ostrzeżeniem o sprzężeniu ze
ScrubUrlTransform.

Odnotowane, poza zakresem

frames[N].args[0] (pozycyjne argumenty) nie są czyszczone ani przed, ani po
tej zmianie — pyrollbar czyści tylko nazwane. To nie regresja, ale przy
przeglądzie maskowania warto o tym wiedzieć.

Lokalnie: src/bpp/tests/ + src/django_bpp/tests/ — 2968 passed, 2 skipped.