admin-mrrm/mrrmlabapp

Fork 0

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

New issue

Closed

opened 2026-05-25 22:31:28 +02:00 by pm-bot · 1 comment

pm-bot commented

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

Collaborator

Kontext

Ausgegliedert aus #404, wo es als "separater Konsistenz-Bug" beschrieben ist. QA-Hut: gehört in ein eigenes Issue, weil anderer Fix-Scope und Sicherheitsrelevanz.

Beobachtung

Bei abgelaufenem ID-Token wirft die Auth-Layer ID token expired, aber die Listen-Daten werden trotzdem gerendert — vermutlich aus Client-Cache oder mit altem Token, der nur auf Auth-Layer geprüft wird, nicht in der API-Layer.

Warum eigenes Issue (nicht Teil von #404)

Anderer Code-Pfad: #404 = Refresh-/Error-Handling in Auth-Layer. Hier = API-Client-Caching / Token-Propagation.
Sicherheitsrelevanz: Falls Backend abgelaufene Tokens akzeptiert, ist das ein Server-Bug, nicht Client.
Risiko: Bei reinem #404-Fix bleibt dieser Pfad bestehen → subtile State-Drift, schwer zu reproduzieren.

Fragen die zu klären sind

Akzeptiert das Backend abgelaufene Tokens? Test: curl mit abgelaufenem JWT gegen /api/lists → erwartet 401, falls 200 = Backend-Bug.
Falls Backend korrekt 401 zurückgibt → woher kommen die Listen im UI? Client-Cache der nicht invalidiert wird?
Was passiert mit Schreib-Operationen (POST/PUT) mit abgelaufenem Token? Geht das durch?

Akzeptanz

API gibt 401 bei abgelaufenem Token zurück (Server-seitig validiert)
Client invalidiert bei 401 den Cache und triggert Re-Auth (verzahnt mit #404)
Lists werden nicht mit Stale-Auth-State gerendert
Curl-Test in PR-Body dokumentiert

Blockiert nicht v0.4.6-Hotfix-Cut (Stacktrace-Fix aus #404 reicht für sichtbares Symptom), aber sollte direkt danach gefixt werden.
Parent: #404

## Kontext Ausgegliedert aus #404, wo es als _"separater Konsistenz-Bug"_ beschrieben ist. QA-Hut: gehört in ein eigenes Issue, weil anderer Fix-Scope und Sicherheitsrelevanz. ## Beobachtung Bei abgelaufenem ID-Token wirft die Auth-Layer `ID token expired`, **aber** die Listen-Daten werden trotzdem gerendert — vermutlich aus Client-Cache oder mit altem Token, der nur auf Auth-Layer geprüft wird, nicht in der API-Layer. ## Warum eigenes Issue (nicht Teil von #404) - **Anderer Code-Pfad:** #404 = Refresh-/Error-Handling in Auth-Layer. Hier = API-Client-Caching / Token-Propagation. - **Sicherheitsrelevanz:** Falls Backend abgelaufene Tokens akzeptiert, ist das ein Server-Bug, nicht Client. - **Risiko:** Bei reinem #404-Fix bleibt dieser Pfad bestehen → subtile State-Drift, schwer zu reproduzieren. ## Fragen die zu klären sind 1. Akzeptiert das Backend abgelaufene Tokens? Test: `curl` mit abgelaufenem JWT gegen `/api/lists` → erwartet 401, falls 200 = Backend-Bug. 2. Falls Backend korrekt 401 zurückgibt → woher kommen die Listen im UI? Client-Cache der nicht invalidiert wird? 3. Was passiert mit Schreib-Operationen (POST/PUT) mit abgelaufenem Token? Geht das durch? ## Akzeptanz - [ ] API gibt 401 bei abgelaufenem Token zurück (Server-seitig validiert) - [ ] Client invalidiert bei 401 den Cache und triggert Re-Auth (verzahnt mit #404) - [ ] Lists werden nicht mit Stale-Auth-State gerendert - [ ] Curl-Test in PR-Body dokumentiert ## Related - Blockiert nicht v0.4.6-Hotfix-Cut (Stacktrace-Fix aus #404 reicht für sichtbares Symptom), aber sollte direkt danach gefixt werden. - Parent: #404

pm-bot added the

labels

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

admin-mrrm referenced this issue from a commit

2026-05-25 22:46:24 +02:00

fix(auth): getUser() refresht abgelaufene ID-Tokens statt zu werfen

pm-bot referenced this issue

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

fix(auth): getUser() refresht abgelaufene ID-Tokens — Fixes #404 #410

pm-bot referenced this issue from a commit

2026-05-25 23:11:26 +02:00

fix(auth): getUser() refresht abgelaufene ID-Tokens — Fixes #404 (#410)

pm-bot referenced this issue

2026-05-27 22:43:32 +02:00

Portfolio-Status KW 2026-W22 #412

admin-mrrm referenced this issue from a commit

2026-05-29 13:18:07 +02:00

fix(auth): clear cache + force re-auth on 401

pm-bot referenced this issue from a pull request that will close it,

2026-05-29 13:18:37 +02:00

fix(auth): clear cache + force re-auth on 401 #429

pm-bot closed this issue

2026-05-29 13:35:22 +02:00

pm-bot referenced this issue from a commit

2026-05-29 13:35:23 +02:00

fix(auth): clear cache + force re-auth on 401 (#429)

pm-bot commented

2026-05-30 07:37:52 +02:00

Author

Collaborator

Geschlossen via PR #429 in v0.6.2.

Akzeptanz:

API gibt 401 bei abgelaufenem Token zurück — neuer Integration-Test (apps/api/test/integration/auth.int-spec.ts)
Client invalidiert bei 401 den Cache und triggert Re-Auth — installAuthErrorHandler in @mrrmlab/ui
Lists werden nicht mit Stale-Auth-State gerendert — queryClient.clear() läuft auf AuthError
Curl-Test in PR-Body dokumentiert (als Integration-Test reproducible)

Release: https://git.mrrm.de/admin-mrrm/mrrmlabapp/releases/tag/v0.6.2

Geschlossen via PR #429 in v0.6.2. **Akzeptanz**: - [x] API gibt 401 bei abgelaufenem Token zurück — neuer Integration-Test (`apps/api/test/integration/auth.int-spec.ts`) - [x] Client invalidiert bei 401 den Cache und triggert Re-Auth — `installAuthErrorHandler` in `@mrrmlab/ui` - [x] Lists werden nicht mit Stale-Auth-State gerendert — `queryClient.clear()` läuft auf AuthError - [x] Curl-Test in PR-Body dokumentiert (als Integration-Test reproducible) Release: https://git.mrrm.de/admin-mrrm/mrrmlabapp/releases/tag/v0.6.2

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

admin-mrrm/mrrmlabapp#408

No description provided.

Rows
Columns