Die Arbeit liefert Rolle, Verbindungstrennung, Pruefwerkzeug und Policies fuer
alle 16 offenen Tabellen, schaltet die Trennung aber bewusst NICHT scharf.
Grund, gemessen statt vermutet: im Code stehen 182 Datenbankzugriffe ohne
Mandantenkontext gegen 19 mit. Der Anmeldeweg ist zwingend darunter — er liest
die Benutzerzeile, bevor der Mandant bekannt ist, weil der Mandant erst aus
dieser Zeile kommt. Unter einer Rolle ohne Umgehungsrecht liefert diese Abfrage
nichts, und niemand koennte sich mehr anmelden. Das Scharfschalten ist damit
ein eigener Vorgang, kein Nebeneffekt dieser Arbeit.
Neu im Ledger als #19: SearchProvider und TenderRssFeedSource haben ein
nullable tenantId. Die einfache Policy vergleicht NULL nie gleich, wodurch die
plattformweiten Zeilen nach dem Scharfschalten fuer JEDEN Mandanten
verschwinden wuerden — nicht nur fuer fremde. Heute wirkungslos, beim
Scharfschalten zwingend mitzuloesen. Die richtige Semantik ist eine
Produktentscheidung, deshalb bewusst nicht eigenmaechtig anders geloest.
673/673 Tests gruen, Typpruefung sauber. #18 bleibt offen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
WINDOWS #18: RLS ist heute wirkungslos, weil die Anwendungsrolle
Superuser ist und BYPASSRLS traegt. Der Plan folgt der vorgegebenen
Reihenfolge — erst die Rolle ohne Umgehungsrecht, dann der Nachweis,
dann die Ausweitung auf die 16 fehlenden Tabellen.
Gemessen und im Plan festgehalten: 182 Zugriffe im API-Quelltext laufen
ueber den unskalierten Prisma-Client (nur 19 ueber tenantPrisma),
darunter der Anmeldeweg selbst. Ein Umlegen des Schalters wuerde die
Anwendung aussperren; der Plan bereitet die Umstellung deshalb vor und
misst sie, vollzieht sie aber nicht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
schalli