docs(quick-260911-fh9): Fehlerrichtung fuer Bereich auth messen und aufschreiben
- rls-scratch-check.mjs: dreizehnter Abschnitt runAuthAreaChecks, getrennt von runAuthLookupChecks — misst die Grenze zwischen Anmeldeweg (drei SECURITY-DEFINER-Funktionen, unveraendert) und Nach-Anmeldung (getMe, changePassword, adminResetPassword) ueber den generierten Client; neuer Helfer readSchemaModelScalarFieldNames() filtert Relationsfelder ueber ihren Typ heraus - zehn neue, namentlich benannte Pruefungen (120/120 insgesamt), sechs davon ueber den generierten Client an der auf 15 Spalten erweiterten Wegwerf-Tabelle "User"; pg_proc bestaetigt SECURITY DEFINER/STABLE/festen Suchpfad/LIMIT 1 fuer alle drei Anmeldefunktionen - docs/mandantentrennung-etappe2-fehlerrichtung.md: neuer Abschnitt "## Bereich auth" (h1)-(h5) vor "## Verweis" — Signaltabelle je Pfad, getMe-Kette als "verschluckt" statt "laut", Etappe-3-Vorbehalt, Schwesterweg-Luecke in user.controller.ts Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR
This commit is contained in:
@@ -2470,6 +2470,210 @@ im Bereich `user` — kein eigener Eintrag noetig.
|
||||
- Schema und Migrationen — geprueft und bewusst gelassen, `Tenant` bekommt
|
||||
KEINE Regel.
|
||||
|
||||
## Bereich auth
|
||||
|
||||
Dieser Abschnitt erweitert die Kritikschrift um den Bereich `auth`
|
||||
(Quick-Task 260911-fh9) und beschreibt ihn zum Zeitpunkt seiner Umstellung.
|
||||
Anders als jeder Bereich davor traegt dieser Bereich die Grenze, an der die
|
||||
gesamte Mandantentrennung haengt: der Anmeldeweg (Benutzer suchen, BEVOR der
|
||||
Mandant bekannt ist) wurde bereits in Etappe 1 (260909-eor) ueber drei enge
|
||||
SECURITY-DEFINER-Funktionen geloest und bleibt in diesem Durchlauf
|
||||
unangetastet; gegenstand dieses Durchlaufs sind ausschliesslich die drei
|
||||
Methoden NACH der Anmeldung (`getMe`, `changePassword`,
|
||||
`adminResetPassword`), die in Etappe 1 bewusst liegen gelassen wurden.
|
||||
|
||||
### (h1) Die Messung
|
||||
|
||||
Aufgabe 1 hat `apps/api/scripts/rls-scratch-check.mjs` um einen dreizehnten
|
||||
Abschnitt (`runAuthAreaChecks`) erweitert — ausdruecklich GETRENNT vom
|
||||
bestehenden `runAuthLookupChecks`: jener misst den Anmeldeweg VOR bekanntem
|
||||
Mandanten (die drei Funktionen ueber `$queryRaw`), dieser die drei Methoden
|
||||
NACH der Anmeldung (gebundener Modellzugriff ueber den GENERIERTEN Client).
|
||||
Der neue Abschnitt setzt auf der von `runAuthLookupChecks` bereits angelegten
|
||||
Wegwerf-Tabelle `"User"` auf (eingeschalteter und erzwungener Zeilenschutz,
|
||||
wortgleiche Policy, zwei Zeilen in zwei Mandanten; seit `runTenantAreaChecks`
|
||||
zusaetzlich mit Fremdschluessel auf `"Tenant"`) und ruestet sie um die fuenf
|
||||
Spalten nach, die der generierte Client zusaetzlich braucht (`createdAt`,
|
||||
`updatedAt`, `lastLoginAt`, `avatarPath`, `accentColor` — Befund G): dafuer
|
||||
liest ein neuer Helfer `readSchemaModelScalarFieldNames('User')` die
|
||||
skalaren Felder aus `schema.prisma` und filtert Relationsfelder ueber ihren
|
||||
Typ heraus (`tenant`, `passwordResetTokens`, `groupMemberships`,
|
||||
`moduleGrants` fallen weg, `role` bleibt — `Role` ist ein `enum`, kein
|
||||
`model`). Diese Spaltenpruefung steht VOR den Client-Pruefungen und bricht
|
||||
den Abschnitt ab, wenn sie durchfaellt (Lehre aus Pruefung 8 im Bereich
|
||||
`calendar`).
|
||||
|
||||
Tatsaechlich beobachtete Ausgabe dieses Laufs (2026-09-11, gegen
|
||||
`tessera-ctl-db-1`, Adresse `172.19.0.2`):
|
||||
|
||||
```
|
||||
auth-wegwerftabelle-user-deckt-alle-spalten-des-generierten-clients: bestanden — Schema-Felder aus schema.prisma (model User, skalare Felder ohne Relationen, 15): ["accentColor","avatarPath","createdAt","displayName","email","id","isActive","lastLoginAt","ldapDn","mustChangePassword","passwordHash","role","tenantId","updatedAt","username"]; Spalten der Wegwerf-Tabelle (15): ["accentColor","avatarPath","createdAt","displayName","email","id","isActive","lastLoginAt","ldapDn","mustChangePassword","passwordHash","role","tenantId","updatedAt","username"]
|
||||
auth-anmeldefunktionen-security-definer-unveraendert: bestanden — 3 Funktion(en) unter 'auth_lookup_%' gefunden: ["auth_lookup_reset_token","auth_lookup_user_by_email","auth_lookup_user_by_username"]; je Funktion prosecdef/provolatile/proconfig/LIMIT-1: [{"proname":"auth_lookup_reset_token","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true},{"proname":"auth_lookup_user_by_email","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true},{"proname":"auth_lookup_user_by_username","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true}]
|
||||
auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz: bestanden — auth_lookup_user_by_username('alice') liefert 1 Zeile(n) mit 9 Schluessel(n): ["displayName","id","isActive","ldapDn","mustChangePassword","passwordHash","role","tenantId","username"] — der feste Spaltensatz der Funktion laesst die Spaltenerweiterung nicht durch
|
||||
auth-getme-generierter-client-ungebunden-liefert-null: bestanden — ungebundenes prisma.user.findUnique({ where: { id: 'user-a' }, select: {...} }) (die Form von getMe) liefert null — das ist der Wert, den GET /auth/me nach dem Scharfschalten als leeren Rumpf ausliefert
|
||||
auth-getme-generierter-client-gebunden-eigener-mandant-findet-benutzer: bestanden — gebunden unter TENANT-A liefert findUnique({ where: { id: 'user-a' }, select: {...} }): {"id":"user-a","username":"alice","displayName":null,"role":"USER","tenantId":"TENANT-A","mustChangePassword":false,"passwordHash":"hash-a","ldapDn":null,"avatarPath":null,"accentColor":null}
|
||||
auth-getme-generierter-client-gebunden-fremder-mandant-liefert-null: bestanden — gebunden unter TENANT-B liefert findUnique({ where: { id: 'user-a' } }) (gehoert TENANT-A): null — ein Administrator von TENANT-B sieht 'user-a' nicht, die Datenbankseite von T-FH9-01
|
||||
auth-changepassword-generierter-client-ungebundenes-update-scheitert-laut: bestanden — ungebundenes prisma.user.update({ where: { id: 'user-a' }, data: {...} }) (die Form von changePassword) wirft PrismaClientKnownRequestError (code P2025): Invalid `prisma.user.update()` invocation: An operation failed because it depends on one or more records that were required but not found. No record was found for an update. — die Wartungsrolle liest danach weiterhin passwordHash="hash-a"
|
||||
auth-changepassword-generierter-client-gebundenes-update-eigener-mandant-gelingt: bestanden — gebunden unter TENANT-A liefert die Wartungsrolle danach passwordHash="hash-a-neu", updatedAt="2026-09-11T09:42:42.165Z" — bestaetigt nebenbei, dass die Wegwerf-Tabelle die clientseitig gesetzten Werte annimmt
|
||||
auth-adminreset-generierter-client-gebundenes-update-fremder-mandant-scheitert-laut: bestanden — gebunden unter TENANT-B liefert update({ where: { id: 'user-a' } }) (gehoert TENANT-A) PrismaClientKnownRequestError (code P2025): Invalid `prisma.user.update()` invocation: An operation failed because it depends on one or more records that were required but not found. No record was found for an update. — ein ADMIN von TENANT-B kann das Kennwort von 'user-a' nicht setzen, gemessen statt behauptet; die Wartungsrolle liest danach weiterhin passwordHash="hash-a-neu"
|
||||
auth-fan-out-je-mandant-gebunden-loest-mandant-der-kennung-auf: bestanden — Fan-out ueber 2 Mandant(en): 'user-a' gefunden unter "TENANT-A", tenantId der Zeile="TENANT-A" — die Kennung allein ergibt den Mandanten des Ziels, weil User.id plattformweit eindeutig ist
|
||||
Alle 120 Pruefungen bestanden.
|
||||
```
|
||||
|
||||
Die tragende Belegzeile ist `auth-getme-generierter-client-ungebunden-liefert-null`: der IDENTISCHE `findUnique`, den `getMe` heute stellt, liefert UNGEBUNDEN `null`, waehrend die Wartungsrolle die Zeile sieht — das ist der Wert, den `GET /auth/me` nach dem Scharfschalten als leeren Rumpf ausliefert. Die `pg_proc`-Messung
|
||||
(`auth-anmeldefunktionen-security-definer-unveraendert`) und der feste
|
||||
Spaltensatz (`auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz`)
|
||||
belegen zusammen, dass die drei Anmeldefunktionen unangetastet sind und die
|
||||
Spaltenerweiterung von `"User"` nichts Zusaetzliches preisgibt: alle drei
|
||||
Funktionen sind weiterhin `SECURITY DEFINER`, `STABLE`, mit festem Suchpfad
|
||||
`search_path=public, pg_temp` und `LIMIT 1`, und `auth_lookup_user_by_username`
|
||||
liefert nach der Spaltenerweiterung weiterhin genau neun Spalten — weder
|
||||
`avatarPath` noch `accentColor` noch `email` sind darunter.
|
||||
|
||||
Sechs der zehn Pruefungen laufen ueber den GENERIERTEN CLIENT
|
||||
(`prisma.user.findUnique`/`update`, `bound.user.findUnique`/`update`), nicht
|
||||
ueber Roh-SQL — bewusst, weil `findUnique` ohne `select` (die Form von
|
||||
`changePassword`/`adminResetPassword`) und das `select` von `getMe` Client-
|
||||
Formen sind: Roh-SQL sieht sie strukturell nicht (Fehler 7 des Vorhabens).
|
||||
|
||||
### (h2) Signaltabelle je Pfad
|
||||
|
||||
| Pfad | `@Public()` | Verhalten HEUTE nach dem Scharfschalten (ohne diesen Plan) | Konkretes Signal | Frontend laesst es durch? |
|
||||
|---|---|---|---|---|
|
||||
| `validateUser` (`POST /auth/login`) | ja | Sucht ueber `auth_lookup_user_by_username` (Funktion, unveraendert) — findet den Benutzer weiterhin, dann gebundener `lastLoginAt`-Schreibzugriff | Anmeldung funktioniert unveraendert | — |
|
||||
| `requestPasswordReset` (`POST /auth/request-reset`) | ja | Sucht ueber `auth_lookup_user_by_email` (Funktion, unveraendert), dann gebundene Token-Anlage | Unveraendert, immer `200` (T-02-12) | — |
|
||||
| `resetPassword` (`POST /auth/reset-password`) | ja | Sucht ueber `auth_lookup_reset_token` (Funktion, unveraendert), dann gebundenes Kennwort-Update und Token-Markierung | Unveraendert | — |
|
||||
| `login`/`logout` | ja/nein | Kein Datenbankzugriff | Keins | — |
|
||||
| `getMe` (`GET /auth/me`) | nein | Vor diesem Plan: ungebundener `findUnique` liefert `null` (`auth-getme-generierter-client-ungebunden-liefert-null`) statt der eigenen Zeile | `200` mit leerem Rumpf statt der Profildaten | Ja — verschluckt, siehe (h3) |
|
||||
| `changePassword` (`POST /auth/change-password`) | nein | Vor diesem Plan: ungebundener `findUnique` liefert `null` | `UnauthorizedException('User not found or has no local password')`, `401` | Ja — als `networkError`, siehe (h3) |
|
||||
| `adminResetPassword`, ADMIN-Zweig (`POST /auth/admin-reset-password/:userId`) | nein | Vor diesem Plan: ungebundener `findUnique` sieht Ziele JEDES Mandanten — Rechteausweitung ueber die Mandantengrenze (T-FH9-01), kein Frontend-Aufrufer | `BadRequestException('User not found')` nur, wenn die Kennung gar nicht existiert; ein fremdmandantiges Ziel wuerde heute GEFUNDEN | Kein UI-Aufrufer (gemessen, Befund D) |
|
||||
| `adminResetPassword`, SUPER_ADMIN-Zweig | nein | Dieselbe Ausweitung; zusaetzlich keine Rollenpruefung des Ziels (T-FH9-04) | Dieselbe Meldung | Kein UI-Aufrufer |
|
||||
|
||||
Nach der Bindung (Aufgabe 2) loest der SUPER_ADMIN-Zweig den Mandanten des
|
||||
Ziels ueber den gebundenen Fan-out `UserService.findByIdForPlatformAdmin`
|
||||
auf — denselben Praezedenzfall, den `user.controller.ts` (`resolveTargetUser`,
|
||||
260910-das) fuer seine eigene Rollenverzweigung benutzt; der ADMIN-Zweig
|
||||
bindet dagegen an `currentUser.tenantId` aus dem Sitzungsnachweis.
|
||||
|
||||
### (h3) Welcher Code Leere als Abwesenheit deutet
|
||||
|
||||
Die `getMe`-Kette, alle vier Glieder namentlich: `getMe` liefert `null` (die
|
||||
Belegzeile `auth-getme-generierter-client-ungebunden-liefert-null`) →
|
||||
`AuthController.me` gibt `null` zurueck, ohne zu werfen → NestJS'
|
||||
`ExpressAdapter.reply` sendet bei `isNil(body)` einen LEEREN Rumpf mit
|
||||
Status `200` (`apps/api/node_modules/@nestjs/platform-express/adapters/express-adapter.js`,
|
||||
Methode `reply`) → `fetchCurrentUser` (`apps/web/src/lib/auth-actions.ts`)
|
||||
laeuft mit `response.json()` auf den leeren Rumpf, faengt im `catch` und
|
||||
liefert `null` → `apps/web/src/components/layout/header.tsx` (`if (u)
|
||||
setUser(...)`) und `apps/web/src/components/settings/account-settings-form.tsx`
|
||||
(`if (u) ...`) tun bei `null` NICHTS. Folge: die Portalhuelle rendert OHNE
|
||||
angemeldeten Benutzer — kein Name, kein Avatar, `isAdmin` falsch, Admin-
|
||||
Navigation weg. Der Auftrag vermutete hier "laut"; die Lesung ergibt
|
||||
**verschluckt**: `fetchCurrentUser` liefert fuer "nicht angemeldet" und
|
||||
"Zeile unsichtbar" denselben Wert `null` — das ist NICHT die Familie eines
|
||||
lauten Fehlers, sondern dieselbe Familie wie WINDOWS #23/#25/#26. Die Seite
|
||||
`apps/web/src/app/(portal)/change-password/page.tsx` haengt an demselben
|
||||
Aufruf; `ForcePasswordChangeInterceptor` laesst `/auth/me` und
|
||||
`/auth/change-password` ausdruecklich durch, weil der erzwungene
|
||||
Kennwortwechsel `getMe` braucht.
|
||||
|
||||
`changePassword`: der gebundene `findUnique` liefert nach der Bindung `null`
|
||||
fuer ein fremdmandantiges Ziel (kommt hier praktisch nicht vor — der
|
||||
angemeldete Benutzer sucht sich selbst) → `UnauthorizedException('User not
|
||||
found or has no local password')`, `401` → `auth-actions.ts` uebersetzt NUR
|
||||
die woertliche Meldung `Current password is incorrect` in
|
||||
`wrongCurrentPassword`, jede andere 401-Meldung in `networkError` — der
|
||||
Nutzer saehe eine Netzwerkfehler-Meldung fuer einen Trennungsfehler. Der
|
||||
Auftrag vermutete "falsches altes Kennwort"; gemessen ist es `networkError`.
|
||||
|
||||
`adminResetPassword`: `BadRequestException('User not found')`, `400`, kein
|
||||
UI-Aufrufer (Befund D) — fuer einen API-Aufrufer bedeutet das "diesen
|
||||
Benutzer gibt es nicht", und fuer ein fremdmandantiges Ziel ist das NACH der
|
||||
Bindung dieses Plans die RICHTIGE Antwort: sie macht keine Aussage ueber die
|
||||
Existenz oder den Mandanten eines fremden Halters (dieselbe Form wie
|
||||
T-DAS-08).
|
||||
|
||||
### (h4) Was dieser Durchlauf bewusst nicht löst
|
||||
|
||||
**(a) Etappe 3.** Die Etappe-3-Entscheidung (1) macht `username` (und
|
||||
`email`) je Mandant eindeutig. Davon betroffen, alles NICHT dieser Auftrag:
|
||||
`auth_lookup_user_by_username(p_username)` (stuetzt sich heute auf `username
|
||||
@unique` plattformweit; braucht kuenftig `(p_tenant_id, p_username)` — die
|
||||
Funktion wird dabei ENGER, zwei Gleichheitsbedingungen statt einer, nicht
|
||||
weiter), gegebenenfalls `auth_lookup_user_by_email`, `local.strategy.ts`
|
||||
(kennt nur `username`/`password`, braucht eine Mandantenangabe VOR der
|
||||
Suche), die `@unique`-Indizes auf `User`, `UserService.findByUsername`,
|
||||
`resolveEmailForWrite` (ldap), die P2002-Uebersetzung in `UserService.create`/
|
||||
`update` (WINDOWS #22). Dieser Plan ist dafuer NEUTRAL: die Bindung der drei
|
||||
Methoden haengt am Claim `tenantId` (das es unabhaengig davon gibt, WIE der
|
||||
Anmeldeweg den Mandanten ermittelt) und an `User.id` (plattformweite UUID,
|
||||
Kette aus 260911-cwh: Schema → `auth.service.ts` `sub: user.id` →
|
||||
`JwtStrategy.validate` → `@CurrentUser().id`) — nicht an `username`/`email`.
|
||||
Unterlassen, damit Etappe 3 nicht schwerer wird: Selbstbedienung ueber
|
||||
`req.tenantId` binden; den Mandanten irgendwo nach der Anmeldung aus
|
||||
`username`/`email` ableiten; die Funktionen um Spalten erweitern.
|
||||
|
||||
**(b) Die Rechteausweitung ADMIN → SUPER_ADMIN im Schwesterweg.**
|
||||
`apps/api/src/user/user.controller.ts`, `update` (Zeilen 172-208) prueft mit
|
||||
T-02-08 nur, ob die Rolle `SUPER_ADMIN` NEU ZUGEWIESEN wird
|
||||
(`dto.role === Role.SUPER_ADMIN`), nicht, ob das ZIEL diese Rolle bereits
|
||||
HAT — `password`/`isActive` im `UpdateUserDto` gehen fuer ein bestehendes
|
||||
`SUPER_ADMIN`-Ziel ungeprueft durch. `remove` (Zeilen 220-244) prueft
|
||||
ueberhaupt keine Rolle des Ziels, nur Selbstloeschung und Mandantengrenze.
|
||||
Erneut gelesen (260911-fh9, Aufgabe 1): beide Luecken bestehen unveraendert
|
||||
— `grep -n "Role.SUPER_ADMIN" apps/api/src/user/user.controller.ts` findet
|
||||
nur die eine Stelle in `update` (`dto.role === Role.SUPER_ADMIN`), keine im
|
||||
`user`-Objekt selbst. Kein Mandantenproblem, sondern Rechteausweitung
|
||||
INNERHALB des Mandanten — derselbe Fall wie T-FH9-04 in diesem Plan, nur am
|
||||
Schwesterweg. Reparatur in einem Satz: die Rolle des ZIELS pruefen (ist
|
||||
`user.role === Role.SUPER_ADMIN` und der Aufrufer nicht `SUPER_ADMIN`,
|
||||
`ForbiddenException`) — die Vorlage steht seit dieser Aufgabe in
|
||||
`AuthService.adminResetPassword`. Ausserhalb der Erlaubnisliste dieses
|
||||
Plans, deshalb Ledger-Eintrag statt Reparatur (Aufgabe 3, T-FH9-05).
|
||||
|
||||
**(c) Das Frontend, das `null` verschluckt.** Nicht angefasst (siehe (h3));
|
||||
Ledger-Eintrag in Aufgabe 3, Familie #23/#25/#26.
|
||||
|
||||
**(d) Die fehlende Existenzpruefung des `x-tenant-id`-Werts.** Bekannt aus
|
||||
`(n4)(f)` des Abschnitts `## Bereich tenant`; hier nur genannt, weil sie die
|
||||
Entscheidung gegen `req.tenantId` fuer Selbstbedienung stuetzt — ein
|
||||
SUPER_ADMIN kann per `x-tenant-id` eine erfundene Kennung schicken, sie
|
||||
bindet an einen leeren Kontext, kein Leck. Nicht dieser Auftrag.
|
||||
|
||||
**(e) Die Etappe-4-Vorabpruefung.** Fuer einen bekannten Benutzer die Zeile
|
||||
ueber die Wartungsrolle lesen und den gebundenen `findUnique` unter seinem
|
||||
Claim-Mandanten daneben halten — dieselbe Form wie bei den Bereichen `user`
|
||||
und `tenant`.
|
||||
|
||||
**(f) `changePassword` hat zwei verschiedene 401-Meldungen.**
|
||||
`User not found or has no local password` (kein lokales Kennwort, z. B.
|
||||
LDAP-Konto) vs. `Current password is incorrect` (falsches Kennwort) —
|
||||
bestehendes Verhalten, betrifft nur die eigene Zeile des angemeldeten
|
||||
Benutzers, unveraendert in diesem Plan.
|
||||
|
||||
### (h5) Was dieser Durchlauf bewusst nicht anfasst
|
||||
|
||||
- Die drei SECURITY-DEFINER-Funktionen aus Etappe 1
|
||||
(`auth_lookup_user_by_username`, `auth_lookup_user_by_email`,
|
||||
`auth_lookup_reset_token`) und ihre Migration `20260909160000_auth_lookup_functions`
|
||||
— belegt durch `git diff --name-only 6236b30 -- apps/api/prisma` (leer)
|
||||
und die `pg_proc`-Messung aus (h1).
|
||||
- Die drei `$queryRaw`-Aufrufe in `validateUser`, `requestPasswordReset`,
|
||||
`resetPassword` — bleiben auf dem ungebundenen Klienten `this.prisma`.
|
||||
- `local.strategy.ts` und `jwt.strategy.ts` — nur gelesen.
|
||||
- `apps/api/src/auth/dto/admin-reset-password.dto.ts` — nur gelesen, kein
|
||||
Mandantenfeld.
|
||||
- `docs/mandantentrennung-datenbankrolle.md`, Abschnitt 3 — beschreibt die
|
||||
Anordnung des Anmeldewegs korrekt, keine Aenderung noetig.
|
||||
- `docs/anleitung-entwicklung.md` — nennt keine der drei Methoden.
|
||||
- `apps/api/src/user/user.controller.ts` — nur gelesen (siehe (h4)(b)).
|
||||
- Das Frontend (`header.tsx`, `account-settings-form.tsx`, `auth-actions.ts`,
|
||||
`change-password/page.tsx`) — nur beschrieben, nicht geaendert.
|
||||
- Schema und Migrationen.
|
||||
- Die Kopfzeile in `auth.service.spec.ts` (Zeile 4-6), die auf ein Muster in
|
||||
`ldap.service.spec.ts` verweist — wird in Aufgabe 2 ersetzt, hier nur als
|
||||
Befund F genannt.
|
||||
|
||||
## Verweis
|
||||
|
||||
Die Bestandsaufnahme, welche Fundstelle den hier beschriebenen Übergang
|
||||
|
||||
Reference in New Issue
Block a user