[Bug] Auth: abgelaufener ID-Token zeigt rohen JS-Stacktrace statt Silent-Refresh oder Re-Login

pm-bot commented

2026-05-25 11:17:03 +02:00

Collaborator

Beobachtung

Beim Öffnen der Web-App (app.mrrm.de/lists) erscheint prominent als rote User-facing Box ein roher JavaScript-Stacktrace:

UNHANDLED PROMISE: Error: ID token expired
    at v2 (https://app.mrrm.de/assets/index-BoOML86G.js:112:145835)
    at async oie.getUser (https://app.mrrm.de/assets/index-BoOML86G.js:112:150947)

Die App rendert die Listen darunter trotzdem — die Seite ist also nicht komplett kaputt, nur das Auth-State-Handling beim Initial-Load.

Stand: 2026-05-25 11:13 (Stakeholder-Report mit Screenshot).

Erwartetes Verhalten

Bei abgelaufenem ID-Token sollte einer dieser zwei Pfade greifen:

A) Silent Refresh: Refresh-Token nutzen um einen neuen ID-Token zu holen, ohne dass der User etwas merkt
B) Re-Login-Redirect: Wenn Refresh nicht möglich, direkt zur Login-Seite mit ?returnTo=…, nicht mit Stacktrace im UI

In keinem Fall darf ein roher Stacktrace User-facing erscheinen.

Aktuelles Verhalten

oie.getUser wirft Error: ID token expired
Die Promise-Rejection wird nicht gefangen
Globale Error-Boundary / Toast-Layer zeigt den Raw-Error
Listen-Daten kommen trotzdem (vermutlich aus Cache oder mit altem Token, der nur auf der Auth-Layer aber nicht auf der API-Layer geprüft wird — das ist ein separater Konsistenz-Bug)

Zwei Bugs in einem

Auth-Refresh fehlt — abgelaufener ID-Token wird nicht erneuert
Error-Handling fehlt — unhandled promise rejection landet im UI als Stacktrace

Beide sollten zusammen gefixt werden, da das Fehlen von (2) den Schaden von (1) erst sichtbar macht.

Reproduktion

Web-App öffnen wenn der ID-Token vor längerer Zeit ausgestellt wurde (>Token-Lifetime)
Initial-Render löst getUser aus → Fehler

Impact

User-facing: Vertrauensschaden, „App ist kaputt"-Eindruck obwohl funktional
Häufigkeit: Vermutlich jedes Mal wenn ein User die App nach längerer Pause öffnet
Workaround: Seite reloaden + neu einloggen

Mögliche Ursache (Anmerkung PM, kein Tech-Call)

Build-Hash index-BoOML86G.js ist der aktuelle Prod-Build nach dem Versions-Sync-Merge gestern Abend (PR #401, Commit 710c785). Sehr unwahrscheinlich dass die Versions-Sync das eingeführt hat — der Auth-Code wurde dort nicht angefasst. Aber wert zu verifizieren ob das vor dem Merge auch schon passiert ist.

Akzeptanzkriterien

Abgelaufener ID-Token triggert Silent-Refresh (falls Refresh-Token gültig)
Fallback: Redirect zur Login-Seite mit Return-URL
Globale unhandled-promise-Boundary verhindert Raw-Stacktrace im UI
Test: Token künstlich invalidieren → kein Stacktrace, Re-Login klappt

## Beobachtung Beim Öffnen der Web-App (`app.mrrm.de/lists`) erscheint **prominent als rote User-facing Box** ein roher JavaScript-Stacktrace: ``` UNHANDLED PROMISE: Error: ID token expired at v2 (https://app.mrrm.de/assets/index-BoOML86G.js:112:145835) at async oie.getUser (https://app.mrrm.de/assets/index-BoOML86G.js:112:150947) ``` Die App rendert die Listen darunter trotzdem — die Seite ist also nicht komplett kaputt, nur das Auth-State-Handling beim Initial-Load. Stand: 2026-05-25 11:13 (Stakeholder-Report mit Screenshot). ## Erwartetes Verhalten Bei abgelaufenem ID-Token sollte einer dieser zwei Pfade greifen: - **A) Silent Refresh:** Refresh-Token nutzen um einen neuen ID-Token zu holen, ohne dass der User etwas merkt - **B) Re-Login-Redirect:** Wenn Refresh nicht möglich, direkt zur Login-Seite mit `?returnTo=…`, **nicht** mit Stacktrace im UI In keinem Fall darf ein roher Stacktrace User-facing erscheinen. ## Aktuelles Verhalten - `oie.getUser` wirft `Error: ID token expired` - Die Promise-Rejection wird nicht gefangen - Globale Error-Boundary / Toast-Layer zeigt den Raw-Error - Listen-Daten kommen trotzdem (vermutlich aus Cache oder mit altem Token, der nur auf der Auth-Layer aber nicht auf der API-Layer geprüft wird — das ist ein **separater** Konsistenz-Bug) ## Zwei Bugs in einem 1. **Auth-Refresh fehlt** — abgelaufener ID-Token wird nicht erneuert 2. **Error-Handling fehlt** — unhandled promise rejection landet im UI als Stacktrace Beide sollten zusammen gefixt werden, da das Fehlen von (2) den Schaden von (1) erst sichtbar macht. ## Reproduktion - Web-App öffnen wenn der ID-Token vor längerer Zeit ausgestellt wurde (>Token-Lifetime) - Initial-Render löst `getUser` aus → Fehler ## Impact - **User-facing:** Vertrauensschaden, „App ist kaputt"-Eindruck obwohl funktional - **Häufigkeit:** Vermutlich jedes Mal wenn ein User die App nach längerer Pause öffnet - **Workaround:** Seite reloaden + neu einloggen ## Mögliche Ursache (Anmerkung PM, kein Tech-Call) Build-Hash `index-BoOML86G.js` ist der aktuelle Prod-Build nach dem Versions-Sync-Merge gestern Abend (PR #401, Commit `710c785`). **Sehr unwahrscheinlich** dass die Versions-Sync das eingeführt hat — der Auth-Code wurde dort nicht angefasst. Aber wert zu verifizieren ob das vor dem Merge auch schon passiert ist. ## Akzeptanzkriterien - [ ] Abgelaufener ID-Token triggert Silent-Refresh (falls Refresh-Token gültig) - [ ] Fallback: Redirect zur Login-Seite mit Return-URL - [ ] Globale unhandled-promise-Boundary verhindert Raw-Stacktrace im UI - [ ] Test: Token künstlich invalidieren → kein Stacktrace, Re-Login klappt

pm-bot added this to the v0.4.5 — App-Shell & Listen-UX milestone

2026-05-25 11:17:03 +02:00

pm-bot added the

labels

2026-05-25 11:17:03 +02:00

pm-bot modified the milestone from v0.4.5 — App-Shell & Listen-UX to v0.4.6 — Auth-Hotfix

2026-05-25 11:37:36 +02:00

pm-bot referenced this issue

2026-05-25 11:37:39 +02:00

[Sprint-Queue] v0.4.5 — Reihenfolge für Devs #400

pm-bot referenced this issue

2026-05-25 11:37:40 +02:00

[Sprint-Queue] v0.4.6 — Hotfix-Reihenfolge für Devs #405

pm-bot commented

2026-05-25 22:30:20 +02:00

Author

Collaborator

QA-Reproduzier-Rezept (Vorschlag)

QA-Hut, gepostet via pm-bot. Damit Smoke-Test reproduzierbar ist:

Browser-DevTools (Web)

App öffnen, einloggen
DevTools → Application → Local/Session-Storage bzw. Cookies
ID-Token-Eintrag finden (vermutlich Auth0/OIDC-Schlüssel)
Token-Payload manuell mit abgelaufenem exp ersetzen — per jwt.io ein Token mit exp < now() generieren. Signatur darf gefälscht sein, wir testen Client-Verhalten, nicht Server-Validierung.
Reload → erwartet: Silent-Refresh oder Login-Redirect, kein Stacktrace im UI

Alternative: Time-Travel

Browser-System-Zeit auf +2h stellen → ID-Token läuft echt ab → Reload

Mobile Native (falls Auth-Stack identisch)

Analog im Native-Storage, oder App 1h+ im Background lassen, dann öffnen

Akzeptanz für #404-Fix

Stacktrace-Box erscheint nicht (kein User-facing Raw-Error)
Entweder Silent-Refresh (User merkt nichts) oder Login-Redirect mit returnTo
Listen werden nach Refresh/Re-Login korrekt nachgeladen (kein API-Cache-Drift — der API-Konsistenz-Teil ist separat als eigenes Issue ausgegliedert)

Reihenfolge fürs Smoke-Sign-off siehe Kommentar in #405.

## QA-Reproduzier-Rezept (Vorschlag) _QA-Hut, gepostet via pm-bot. Damit Smoke-Test reproduzierbar ist:_ ### Browser-DevTools (Web) 1. App öffnen, einloggen 2. DevTools → Application → Local/Session-Storage bzw. Cookies 3. ID-Token-Eintrag finden (vermutlich Auth0/OIDC-Schlüssel) 4. Token-Payload manuell mit abgelaufenem `exp` ersetzen — per jwt.io ein Token mit `exp` < `now()` generieren. Signatur darf gefälscht sein, wir testen Client-Verhalten, nicht Server-Validierung. 5. Reload → erwartet: Silent-Refresh **oder** Login-Redirect, **kein** Stacktrace im UI ### Alternative: Time-Travel - Browser-System-Zeit auf `+2h` stellen → ID-Token läuft echt ab → Reload ### Mobile Native (falls Auth-Stack identisch) - Analog im Native-Storage, oder App 1h+ im Background lassen, dann öffnen ### Akzeptanz für #404-Fix - [ ] Stacktrace-Box erscheint nicht (kein User-facing Raw-Error) - [ ] Entweder Silent-Refresh (User merkt nichts) **oder** Login-Redirect mit `returnTo` - [ ] Listen werden nach Refresh/Re-Login korrekt nachgeladen (kein API-Cache-Drift — der API-Konsistenz-Teil ist separat als eigenes Issue ausgegliedert) Reihenfolge fürs Smoke-Sign-off siehe Kommentar in #405.

pm-bot referenced this issue

2026-05-25 22:30:22 +02:00

[Sprint-Queue] v0.4.6 — Hotfix-Reihenfolge für Devs #405

pm-bot referenced this issue

2026-05-25 22:31:28 +02:00

[Bug] Auth: API-Layer/Cache liefert Lists trotz abgelaufenem ID-Token #408