From 9782bea1b2c9bec125499386e5d8f7fa3acc6e11 Mon Sep 17 00:00:00 2001 From: Schalli Date: Fri, 11 Sep 2026 11:45:58 +0200 Subject: [PATCH] docs(quick-260911-fh9): Fehlerrichtung fuer Bereich auth messen und aufschreiben MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR --- apps/api/scripts/rls-scratch-check.mjs | 332 ++++++++++++++++++ ...andantentrennung-etappe2-fehlerrichtung.md | 204 +++++++++++ 2 files changed, 536 insertions(+) diff --git a/apps/api/scripts/rls-scratch-check.mjs b/apps/api/scripts/rls-scratch-check.mjs index 025b579..a0965ca 100644 --- a/apps/api/scripts/rls-scratch-check.mjs +++ b/apps/api/scripts/rls-scratch-check.mjs @@ -2794,6 +2794,41 @@ function readSchemaModelFieldNames(modelName) { return fields; } +/** + * Aufgabe 1 (260911-fh9) — wie `readSchemaModelFieldNames`, aber laesst + * jedes Feld weg, dessen TYP (zweites Wort der Zeile, `?` und `[]` + * abgestreift) selbst der Name eines anderen `model` im Schema ist — + * Relationsfelder haben keine Spalte (Befund M aus 260911-e2s, dort fuer + * "Tenant" ueber die Migration umgangen; bei "User" ist die Spaltenmenge + * ueber drei Migrationen verteilt, deshalb hier der Weg ueber das Schema + * mit Relationsfilter). `Role` ist ein `enum`, kein `model`, und bleibt + * deshalb ein skalares Feld. + */ +function readSchemaModelScalarFieldNames(modelName) { + const schemaSource = readFileSync(SCHEMA_PRISMA_PATH, 'utf-8'); + const modelNames = new Set( + [...schemaSource.matchAll(/^model\s+(\w+)\s*\{/gm)].map((m) => m[1]), + ); + const re = new RegExp(`model ${modelName} \\{([\\s\\S]*?)\\n\\}`); + const match = schemaSource.match(re); + if (!match) return []; + const fields = []; + for (const rawLine of match[1].split('\n')) { + const line = rawLine.trim(); + if (!line) continue; + if (line.startsWith('@@')) continue; + if (line.startsWith('//')) continue; + const parts = line.split(/\s+/); + const fieldName = parts[0]; + if (!fieldName) continue; + const rawType = parts[1] ?? ''; + const fieldType = rawType.replace(/\?$/, '').replace(/\[\]$/, ''); + if (modelNames.has(fieldType)) continue; // Relationsfeld, keine Spalte + fields.push(fieldName); + } + return fields; +} + /** * Aufgabe 1 (260911-cwh) — misst die zwoelf im Plan genannten * Verhaltensweisen des Bereichs `calendar` unter der Rolle ohne BYPASSRLS, @@ -3445,6 +3480,302 @@ async function runTenantAreaChecks(adminUrl, scratchRoleUrl, results) { } } +/** + * Aufgabe 1 (260911-fh9) — misst die Grenze zwischen Anmeldeweg (die drei + * SECURITY-DEFINER-Funktionen, gemessen in `runAuthLookupChecks`) und + * Nach-Anmeldung (dieser Abschnitt, gebundener Modellzugriff ueber den + * GENERIERTEN Client) fuer die drei Methoden `getMe`, `changePassword`, + * `adminResetPassword`. Ausdruecklich GETRENNT von `runAuthLookupChecks`: + * jener misst den Anmeldeweg VOR bekanntem Mandanten (Funktionen), dieser + * die drei Methoden NACH der Anmeldung (gebundener Modellzugriff) — die + * Grenze, die dieser Plan festnagelt. + * + * Setzt auf der vorhandenen Wegwerf-Tabelle "User" auf (aus + * `runAuthLookupChecks`, mit eingeschaltetem und erzwungenem Zeilenschutz, + * wortgleicher Policy, zwei Zeilen in zwei Mandanten; seit + * `runTenantAreaChecks` zusaetzlich mit Fremdschluessel auf "Tenant") und + * auf der bereits eingespielten Funktions-Migration; erweitert "User" um die + * fuenf im generierten Client fehlenden Spalten (Befund G). Keine spaetere + * Pruefung setzt auf diesen Erweiterungen auf (`runTransactionShapeMeasurement`/ + * `runConcurrencyProbe` fassen weder "User" noch "Tenant" an, Befund M aus + * 260911-e2s) — dieser Abschnitt ist ein Blatt in der Aufrufkette und muss + * deshalb NACH `runTenantAreaChecks()` und VOR + * `runTransactionShapeMeasurement()` laufen (siehe Aufrufkette in `main()`). + */ +async function runAuthAreaChecks(adminUrl, scratchRoleUrl, results) { + // Vorbereitung ueber die Wartungsrolle: die fuenf im generierten Client + // fehlenden Spalten nachruesten (Befund G). Typen aus den drei + // ausgelieferten Migrationen (20260618112124_auth_multi_tenancy, + // 20260630095533_add_user_avatar, 20260702000000_add_user_accent_color). + // ABWEICHUNG: "updatedAt" bekommt fuer die zwei bereits vorhandenen + // Wegwerf-Zeilen (user-a/user-b aus runAuthLookupChecks) eine Vorgabe + // CURRENT_TIMESTAMP, die die ausgelieferte Migration nicht hat (dort NOT + // NULL ohne DEFAULT — Prisma setzt den Wert clientseitig ueber + // `@updatedAt`) — betrifft nur dieses Nachruesten hier, keine Aussage + // ueber den ausgelieferten Stand. + await withAdminPrisma(urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), async (db) => { + await db.$executeRawUnsafe( + `ALTER TABLE "User" ADD COLUMN "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;`, + ); + await db.$executeRawUnsafe( + `ALTER TABLE "User" ADD COLUMN "updatedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;`, + ); + await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "lastLoginAt" TIMESTAMP(3);`); + await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "avatarPath" TEXT;`); + await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "accentColor" TEXT;`); + }); + + // Pruefung — steht VOR den Client-Pruefungen (4-10 unten); faellt sie + // durch, bricht der Abschnitt ab (Lehre aus Pruefung 8 im Bereich + // `calendar`/Pruefung 3 im Bereich `tenant`). + const schemaFields = readSchemaModelScalarFieldNames('User'); + const tableColumns = await withAdminPrisma( + urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), + async (db) => { + const rows = await db.$queryRaw` + SELECT column_name FROM information_schema.columns + WHERE table_schema = 'public' AND table_name = 'User' + `; + return rows.map((r) => r.column_name).sort(); + }, + ); + const schemaFieldsSorted = [...schemaFields].sort(); + const columnsMatch = + schemaFieldsSorted.length > 0 && + schemaFieldsSorted.length === tableColumns.length && + schemaFieldsSorted.every((f, i) => f === tableColumns[i]); + report( + results, + 'auth-wegwerftabelle-user-deckt-alle-spalten-des-generierten-clients', + columnsMatch, + `Schema-Felder aus schema.prisma (model User, skalare Felder ohne Relationen, ${schemaFieldsSorted.length}): ${JSON.stringify(schemaFieldsSorted)}; Spalten der Wegwerf-Tabelle (${tableColumns.length}): ${JSON.stringify(tableColumns)}`, + ); + if (!columnsMatch) { + return; + } + + // Pruefung 1: pg_proc-Messung der drei Anmeldefunktionen — die + // Datenbankseite von "nichts an der Anordnung angefasst" (Befund H). + const functionRows = await withAdminPrisma( + urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), + async (db) => + db.$queryRaw` + SELECT proname, prosecdef, provolatile, proconfig, pg_get_functiondef(oid) AS def + FROM pg_proc WHERE proname LIKE 'auth_lookup_%' ORDER BY proname + `, + ); + const expectedFunctionNames = [ + 'auth_lookup_reset_token', + 'auth_lookup_user_by_email', + 'auth_lookup_user_by_username', + ]; + const actualFunctionNames = functionRows.map((r) => r.proname).sort(); + const perFunctionProps = functionRows.map((r) => ({ + proname: r.proname, + prosecdef: r.prosecdef, + provolatile: r.provolatile, + proconfig: r.proconfig, + hatLimit1: typeof r.def === 'string' && r.def.includes('LIMIT 1'), + })); + const allSecurityDefinerStableFixedSearchPathLimit1 = perFunctionProps.every( + (p) => + p.prosecdef === true && + p.provolatile === 's' && + Array.isArray(p.proconfig) && + p.proconfig.some((c) => String(c).replace(/\s+/g, '') === 'search_path=public,pg_temp') && + p.hatLimit1, + ); + const functionsOk = + functionRows.length === 3 && + JSON.stringify(actualFunctionNames) === JSON.stringify(expectedFunctionNames) && + allSecurityDefinerStableFixedSearchPathLimit1; + report( + results, + 'auth-anmeldefunktionen-security-definer-unveraendert', + functionsOk, + `${functionRows.length} Funktion(en) unter 'auth_lookup_%' gefunden: ${JSON.stringify(actualFunctionNames)}; je Funktion prosecdef/provolatile/proconfig/LIMIT-1: ${JSON.stringify(perFunctionProps)}`, + ); + + const prisma = new PrismaClient({ datasourceUrl: scratchRoleUrl }); + try { + // Pruefung 3: die Anmeldesuche findet den Benutzer weiterhin, mit dem + // FESTEN Spaltensatz der Funktion — die Spaltenerweiterung oben laesst + // weder avatarPath noch accentColor noch email durch. + const lookupRows = await prisma.$queryRaw`SELECT * FROM auth_lookup_user_by_username('alice')`; + const lookupKeys = lookupRows.length === 1 ? Object.keys(lookupRows[0]).sort() : []; + const lookupOk = + lookupRows.length === 1 && + lookupKeys.length === 9 && + !lookupKeys.includes('avatarPath') && + !lookupKeys.includes('accentColor') && + !lookupKeys.includes('email'); + report( + results, + 'auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz', + lookupOk, + `auth_lookup_user_by_username('alice') liefert ${lookupRows.length} Zeile(n) mit ${lookupKeys.length} Schluessel(n): ${JSON.stringify(lookupKeys)} — der feste Spaltensatz der Funktion laesst die Spaltenerweiterung nicht durch`, + ); + + // Die tragende Belegzeile: getMe() als Client-Form, UNGEBUNDEN. + const getMeSelect = { + id: true, + username: true, + displayName: true, + role: true, + tenantId: true, + mustChangePassword: true, + passwordHash: true, + ldapDn: true, + avatarPath: true, + accentColor: true, + }; + const unboundGetMe = await prisma.user.findUnique({ + where: { id: 'user-a' }, + select: getMeSelect, + }); + report( + results, + 'auth-getme-generierter-client-ungebunden-liefert-null', + unboundGetMe === null, + `ungebundenes prisma.user.findUnique({ where: { id: 'user-a' }, select: {...} }) (die Form von getMe) liefert ${JSON.stringify(unboundGetMe)} — das ist der Wert, den GET /auth/me nach dem Scharfschalten als leeren Rumpf ausliefert`, + ); + + const boundA = buildInlineExtendedClient(prisma, 'TENANT-A'); + const boundGetMeOwn = await boundA.user.findUnique({ + where: { id: 'user-a' }, + select: getMeSelect, + }); + const ownTenantOk = + Boolean(boundGetMeOwn) && + boundGetMeOwn.tenantId === 'TENANT-A' && + Object.keys(boundGetMeOwn).sort().length === 10; + report( + results, + 'auth-getme-generierter-client-gebunden-eigener-mandant-findet-benutzer', + ownTenantOk, + `gebunden unter TENANT-A liefert findUnique({ where: { id: 'user-a' }, select: {...} }): ${JSON.stringify(boundGetMeOwn)}`, + ); + + const boundB = buildInlineExtendedClient(prisma, 'TENANT-B'); + const boundGetMeForeign = await boundB.user.findUnique({ + where: { id: 'user-a' }, + select: getMeSelect, + }); + report( + results, + 'auth-getme-generierter-client-gebunden-fremder-mandant-liefert-null', + boundGetMeForeign === null, + `gebunden unter TENANT-B liefert findUnique({ where: { id: 'user-a' } }) (gehoert TENANT-A): ${JSON.stringify(boundGetMeForeign)} — ein Administrator von TENANT-B sieht 'user-a' nicht, die Datenbankseite von T-FH9-01`, + ); + + // Die Schreibform, die changePassword heute stellt: UNGEBUNDEN. + let ungebundenesUpdateWarf = false; + let ungebundenesUpdateCtor = 'unbekannt'; + let ungebundenesUpdateCode; + let ungebundenesUpdateMessage = ''; + try { + await prisma.user.update({ + where: { id: 'user-a' }, + data: { passwordHash: 'hash-a-neu-ungebunden', mustChangePassword: false }, + }); + } catch (err) { + ungebundenesUpdateWarf = true; + ungebundenesUpdateCtor = err?.constructor?.name ?? 'unbekannt'; + ungebundenesUpdateCode = err?.code; + ungebundenesUpdateMessage = (err.message ?? '').toString().trim(); + } + const passwordHashNachUngebundenemVersuch = await withAdminPrisma( + urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), + async (db) => { + const rows = await db.$queryRaw`SELECT "passwordHash" FROM "User" WHERE id = 'user-a'`; + return rows[0]?.passwordHash; + }, + ); + report( + results, + 'auth-changepassword-generierter-client-ungebundenes-update-scheitert-laut', + ungebundenesUpdateWarf && passwordHashNachUngebundenemVersuch === 'hash-a', + `ungebundenes prisma.user.update({ where: { id: 'user-a' }, data: {...} }) (die Form von changePassword) wirft ${ungebundenesUpdateCtor}${ungebundenesUpdateCode ? ` (code ${ungebundenesUpdateCode})` : ''}: ${ungebundenesUpdateMessage} — die Wartungsrolle liest danach weiterhin passwordHash=${JSON.stringify(passwordHashNachUngebundenemVersuch)}`, + ); + + // Dasselbe update, GEBUNDEN unter TENANT-A (eigener Mandant): gelingt. + await boundA.user.update({ + where: { id: 'user-a' }, + data: { passwordHash: 'hash-a-neu', mustChangePassword: false }, + }); + const nachGebundenemUpdate = await withAdminPrisma( + urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), + async (db) => { + const rows = + await db.$queryRaw`SELECT "passwordHash", "updatedAt" FROM "User" WHERE id = 'user-a'`; + return rows[0]; + }, + ); + report( + results, + 'auth-changepassword-generierter-client-gebundenes-update-eigener-mandant-gelingt', + nachGebundenemUpdate?.passwordHash === 'hash-a-neu' && nachGebundenemUpdate?.updatedAt != null, + `gebunden unter TENANT-A liefert die Wartungsrolle danach passwordHash=${JSON.stringify(nachGebundenemUpdate?.passwordHash)}, updatedAt=${JSON.stringify(nachGebundenemUpdate?.updatedAt)} — bestaetigt nebenbei, dass die Wegwerf-Tabelle die clientseitig gesetzten Werte annimmt`, + ); + + // Dieselbe Schreibform, GEBUNDEN unter TENANT-B (fremder Mandant): die + // Form, die adminResetPassword fuer ein fremdmandantiges Ziel stellt. + let fremdesUpdateWarf = false; + let fremdesUpdateCtor = 'unbekannt'; + let fremdesUpdateCode; + let fremdesUpdateMessage = ''; + try { + await boundB.user.update({ + where: { id: 'user-a' }, + data: { passwordHash: 'hash-a-fremd' }, + }); + } catch (err) { + fremdesUpdateWarf = true; + fremdesUpdateCtor = err?.constructor?.name ?? 'unbekannt'; + fremdesUpdateCode = err?.code; + fremdesUpdateMessage = (err.message ?? '').toString().trim(); + } + const passwordHashNachFremdemVersuch = await withAdminPrisma( + urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), + async (db) => { + const rows = await db.$queryRaw`SELECT "passwordHash" FROM "User" WHERE id = 'user-a'`; + return rows[0]?.passwordHash; + }, + ); + report( + results, + 'auth-adminreset-generierter-client-gebundenes-update-fremder-mandant-scheitert-laut', + fremdesUpdateWarf && passwordHashNachFremdemVersuch === 'hash-a-neu', + `gebunden unter TENANT-B liefert update({ where: { id: 'user-a' } }) (gehoert TENANT-A) ${fremdesUpdateCtor}${fremdesUpdateCode ? ` (code ${fremdesUpdateCode})` : ''}: ${fremdesUpdateMessage} — ein ADMIN von TENANT-B kann das Kennwort von 'user-a' nicht setzen, gemessen statt behauptet; die Wartungsrolle liest danach weiterhin passwordHash=${JSON.stringify(passwordHashNachFremdemVersuch)}`, + ); + + // Fan-out je Mandant, gebunden: die Form, die Aufgabe 2/3 fuer die + // oberste Rolle (SUPER_ADMIN) benutzt — Tenant ungebunden als Treiber + // (Tenant ohne Regel, gemessen in runTenantAreaChecks), je Mandant EIN + // gebundener findUnique. + const tenantsForFanOut = await prisma.tenant.findMany({ orderBy: { id: 'asc' } }); + let fanOutHit = null; + let fanOutTenantId = null; + for (const t of tenantsForFanOut) { + const boundForT = buildInlineExtendedClient(prisma, t.id); + const hit = await boundForT.user.findUnique({ where: { id: 'user-a' } }); + if (hit) { + fanOutHit = hit; + fanOutTenantId = t.id; + break; + } + } + report( + results, + 'auth-fan-out-je-mandant-gebunden-loest-mandant-der-kennung-auf', + Boolean(fanOutHit) && fanOutTenantId === 'TENANT-A' && fanOutHit.tenantId === 'TENANT-A', + `Fan-out ueber ${tenantsForFanOut.length} Mandant(en): 'user-a' gefunden unter ${JSON.stringify(fanOutTenantId)}, tenantId der Zeile=${JSON.stringify(fanOutHit?.tenantId)} — die Kennung allein ergibt den Mandanten des Ziels, weil User.id plattformweit eindeutig ist`, + ); + } finally { + await prisma.$disconnect(); + } +} + /** * Aufgabe 1 (260909-jts), TEIL 2 — misst, welche der drei Transaktionsformen * den Mandantenkontext auf DERSELBEN Verbindung ueber alle Teilschritte @@ -3683,6 +4014,7 @@ async function main() { await runDashboardAreaChecks(adminUrl, scratchRoleUrlString, results); await runCalendarAreaChecks(adminUrl, scratchRoleUrlString, results); await runTenantAreaChecks(adminUrl, scratchRoleUrlString, results); + await runAuthAreaChecks(adminUrl, scratchRoleUrlString, results); await runTransactionShapeMeasurement(scratchRoleUrlString, results); await runConcurrencyProbe(scratchRoleUrlString, results); } finally { diff --git a/docs/mandantentrennung-etappe2-fehlerrichtung.md b/docs/mandantentrennung-etappe2-fehlerrichtung.md index 3176d21..d9628f1 100644 --- a/docs/mandantentrennung-etappe2-fehlerrichtung.md +++ b/docs/mandantentrennung-etappe2-fehlerrichtung.md @@ -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