internal/authtoken: Einmal-Token fuer Passwort-Reset und Einladung, getrennt
von internal/auth (Sessions/JWT), da der Vorgang bewusst session-los ist.
Store.Create gibt das Klartext-Token NUR an den Aufrufer zurueck (fuer
E-Mail-Versand, IAM-08), gespeichert wird ausschliesslich der SHA-256-Hash.
Store.Consume markiert ein Token atomar als verwendet (UPDATE ... WHERE
used_at IS NULL AND expires_at > now() RETURNING user_id) — Wiederverwendung
und Ablauf werden serverseitig in derselben Datenbankoperation durchgesetzt,
kein Race zwischen Pruefen und Verbrauchen moeglich. Ungueltig, bereits
verwendet und abgelaufen liefern denselben ErrInvalidToken (Akzeptanz-
kriterium 3), damit die Antwort keinen der drei Faelle verraet.
CompletePasswordReset/CompleteInvitation loesen ein Token ein und setzen das
Passwort ueber user.TenantUserStore.SetPasswordHash (IAM-01) — keine
Auth-Middleware, keine Session noetig (Akzeptanzkriterium 2).
Log-Statements bei Create/Consume enthalten bewusst nur user_id/purpose,
niemals das Token selbst.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Wiederverwendung eines bereits eingeloesten Tokens automatisiert
abgewiesen — TestConsume_RejectsReuse. PASS.
2. Ablaufzeit serverseitig durchgesetzt — TestConsume_RejectsExpiredToken
(Token mit negativer TTL sofort abgelaufen). PASS.
3. Token werden nicht im Klartext geloggt (Stichprobe im Log-Ausgang) —
TestCreateAndConsume_NeverLogTokenPlaintext: Log-Buffer nach Create +
ungueltigem + gueltigem Consume enthaelt das Klartext-Token nachweislich
nicht. PASS.
Zusaetzlich: TestCompleteInvitation_SetsPasswordWithoutSession belegt
Akzeptanzkriterium 2 konkret (Passwort gesetzt und verifizierbar, keine
Session im Ablauf beteiligt). PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/tenantsettings: pro-Tenant-Einstellungen (Anzeigename, Logo,
Farbschema, Zeitzone, Sprache) in der Registry-DB, alle Spalten nullable —
fehlender Wert bedeutet immer "Systemvoreinstellung verwenden"
(Defaults(): color_scheme=system, timezone=UTC, language=de), niemals ein
Fehler (Akzeptanzkriterium 2). Store.Update schreibt aktuellen Stand +
Historieneintrag atomar in einer Transaktion mit FOR-UPDATE-Lock auf der
aktuellen Zeile (Akzeptanzkriterium 3, Race-sicher bei nebenlaeufigen
Updates desselben Tenants). Patch-Typ mit *string-Feldern erlaubt
Teil-Updates ohne unbeteiligte Felder zu beruehren.
Schlanker Handler (Get/Update ueber tenant_id-Query-Parameter) als
Vorbereitung der REST-Schnittstelle — echte Auth/Versionierung kommt erst
mit API-01/IAM-02/RBAC-01.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Aenderung eines Tenants wirkt sich nicht auf einen anderen aus —
TestUpdate_IsolatedBetweenTenants: Tenant A geaendert, Tenant B bleibt
nachweislich bei Defaults(). PASS.
2. Fehlende Werte liefern Defaults statt Fehler —
TestGet_UnsetTenantReturnsDefaults (Tenant ganz ohne Datensatz) und
TestUpdate_PartialPatchKeepsOtherFieldsAtDefault (nur ein Feld gesetzt,
Rest bleibt Default). PASS.
3. API-Schema von zweiter Person gegen Dokumentation geprueft — NICHT
durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen.
Zusaetzlich automatisiert getestet (Akzeptanzkriterium 3):
TestUpdate_HistoryTracksVersions — 3 aufeinanderfolgende Aenderungen,
Historie liefert alle 3 in korrekter Reihenfolge, nicht angefasste Felder
bleiben aus dem vorherigen Update erhalten. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Orchestrator.RolloutAll wendet eine geordnete Liste von Migrationen auf JEDE
registrierte Tenant-Datenbank an (LoadMigrations liest *.up.sql aus einem
Verzeichnis nach der bestehenden 000N_name-Namenskonvention). Jeder Tenant
laeuft unabhaengig in eigener Verbindung — ein Fehlschlag bei einem Mandanten
bricht nur dessen eigenen Rollout ab (spaetere Migrationen bauen typischerweise
auf frueheren auf) und blockiert die uebrigen Tenants nicht.
schema_migrations-Tabelle pro Tenant-Datenbank (version PK, applied_at,
success, error) haelt den Stand pro Version einzeln nachvollziehbar fest.
Bereits erfolgreiche Versionen werden bei einem erneuten Rollout uebersprungen
(isAlreadySuccessful-Check vor jeder Anwendung), fehlgeschlagene werden beim
naechsten Versuch automatisch erneut probiert (kein manuelles Zuruecksetzen
noetig) — ON CONFLICT DO UPDATE haelt jeweils nur den letzten Versuch fest.
Bewusst ohne Abhaengigkeit von TEN-06 (Router): Migrations-Rollouts sind
seltene Batch-Vorgaenge, ein kurzlebiger Pool pro Tenant und Lauf reicht.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS,
go test ./... mit -p 1 noetig da mehrere Pakete die geteilte Registry-Tabelle
auf derselben Postgres-Instanz nutzen — siehe scripts/reset-test-env.sh):
1. Rollout gegen 3 Test-Tenants, einer absichtlich inkompatibel (Tabellen-
Konflikt bei Migration 2) — TestRolloutAll_IsolatesFailurePerTenant: die
anderen beiden erhalten beide Migrationen, der inkompatible bekommt
Migration 1 trotzdem, scheitert nur an Migration 2, faellt nicht die
anderen um. PASS.
2. Migrationsstand-Abfrage liefert korrekten Stand pro Tenant —
TestStatus_ReflectsPerTenantState: Version 1 success=true, Version 2
success=false mit Fehlertext. PASS.
3. Wiederholter Rollout fuer fehlgeschlagene Migration moeglich, ohne bereits
erfolgreiche erneut anzuwenden — TestRolloutAll_RetryDoesNotReapplySuccessful:
Migration 1 nutzt bewusst kein IF NOT EXISTS, ein Reapply haette den
zweiten Lauf scheitern lassen; zweiter Lauf ist fehlerfrei und wendet nur
die zuvor fehlgeschlagene Version an. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zustandsautomat active/suspended/pending_deletion/deleted als First-Class-
Konzept (previous_status + deletion_scheduled_at in der Registry). Alle
Uebergaenge in Registry.transition als atomarer Check-and-Set (UPDATE ...
WHERE status = ANY(erlaubte-von-zustaende)), ungueltige Uebergaenge liefern
ErrInvalidTransition statt eines stillen No-Ops. ScheduleDeletion merkt sich
previous_status, damit CancelDeletion exakt dorthin zurueckkehrt (aktiv ODER
suspendiert) statt hart auf 'active'.
Lifecycle.ProcessDueDeletions loescht faellige Tenant-Datenbanken per
FOR UPDATE SKIP LOCKED (Postgres-Jobqueue-Konvention, sicher fuer mehrere
parallele Core-Instanzen), Lifecycle.RunSweeper triggert das periodisch per
In-Prozess-Goroutine. Lifecycle.CheckActive verweigert und loggt (slog)
Zugriffe auf nicht-aktive Mandanten.
Bugfix nebenbei: Registry.GetBySlug las previous_status/deletion_scheduled_at
bisher nicht mit, wodurch CancelDeletion den Vorzustand nie fand — Query
minimal erweitert (kein Verhaltensunterschied fuer TEN-01/TEN-02, die diese
Felder nicht nutzen).
Neu: scripts/reset-test-env.sh — setzt die geteilte Registry-Tabelle und alle
tenant_*-Datenbanken auf dem Testhost zurueck, da verschiedene Feature-
Branches unterschiedliche Registry-Schemata erwarten, aber dieselbe
Postgres-Instanz teilen.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Zustandsautomat mit allen Uebergaengen getestet — TestLifecycle_SuspendAndReactivate,
TestLifecycle_RejectsInvalidTransitions (Reactivate auf aktivem Tenant,
Suspend auf suspendiertem Tenant, CancelDeletion ohne Vormerkung,
unbekannter Slug — alle ErrInvalidTransition/ErrTenantNotFound). PASS.
2. Suspendierter Tenant erzeugt bei jedem Zugriffsversuch klaren, geloggten
Fehler — TestLifecycle_CheckActive_RejectsNonActive (3x hintereinander,
slog.Warn nachweislich pro Aufruf). PASS.
3. Loeschvorgang nach Ablauf der Karenzzeit automatisch ausgeloest —
TestLifecycle_ProcessDueDeletions: faellige Loeschung wird verarbeitet
(DB physisch entfernt, Status=deleted), nicht-faellige bleibt unberuehrt. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Router loest Tenant-Slug (aus JWT-Claim, API-05 vorausgesetzt) ueber die
TEN-01-Registry in eine wiederverwendete Postgres-Verbindung auf. LRU-Cache
(container/list) begrenzt die Zahl gleichzeitig offener Tenant-Pools auf
maxOpen — bei Ueberschreitung wird der am laengsten ungenutzte Pool
geschlossen, bevor ein neuer aufgemacht wird. Fehlender/unbekannter
Tenant-Kontext liefert explizite Fehler (ErrMissingTenantContext /
ErrUnknownTenant) statt stillschweigend zu routen.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Lasttest mit 6 simulierten Mandanten gegen maxOpen=2 — TestRouter_BoundsOpenConnectionsUnderLoad:
OpenCount() bleibt nach jedem Resolve <= maxOpen, Verbindungszahl waechst
nicht linear mit der Mandantenzahl. PASS.
2. Anfrage ohne/mit unbekanntem Tenant-Kontext abgewiesen —
TestRouter_RejectsMissingOrUnknownTenant. PASS.
3. Verbindungswiederverwendung gemessen — TestRouter_ReusesConnectionForSameTenant:
zweiter Resolve-Aufruf liefert exakt dieselbe *pgxpool.Pool-Instanz. PASS.
Router ist eigenstaendig nutzbar/getestet, aber noch nicht in cmd/core/main.go
verdrahtet — der JWT-Claim mit Tenant-Kontext (API-05) und das HTTP-Routing,
das den Slug pro Request extrahiert, sind nicht Teil dieser Kachel.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/auth: Login/Logout ueber httpOnly/Secure/SameSite=Strict-Cookie mit
HS256-JWT (30min TTL), bcrypt-Passwort-Hashing (Cost 12, explizit begruendet
und benchmarkt statt DefaultCost uebernommen), RequireAuth-Middleware fuer
geschuetzte Routen. LoginService ist strukturell auf einen Tenant gescopt
(nutzt user.TenantUserStore, dessen Pool = eine Tenant-DB — derselbe
Mechanismus wie in TEN-01/TEN-02), liefert bei falscher E-Mail und falschem
Passwort denselben Fehler (User-Enumeration-Schutz) inkl. Dummy-bcrypt-
Vergleich gegen Timing-Seitenkanal bei unbekannter E-Mail.
user.TenantUserStore erweitert um SetPasswordHash/GetByEmailForAuth
(password_hash bleibt ausserhalb des regulaeren User-Typs/JSON-Pfads).
Migration 0002 fuegt password_hash-Spalte hinzu (Default '', da IAM-01
User ohne Passwort anlegt).
Login-Handler ist wie IAM-01/TEN-02 aus denselben Gruenden (Tenant-
Connection-Routing = TEN-06, noch nicht gebaut) nicht in cmd/core/main.go
verdrahtet — Package ist eigenstaendig nutzbar/getestet.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Login-Query tenant-gescopt — TestLoginService_NoCrossTenantLogin: gleiche
E-Mail in zwei Tenant-DBs mit unterschiedlichem Passwort, Login gegen
Tenant A mit Tenant-B-Passwort schlaegt fehl. PASS.
2. Session-Fixation/Token-Manipulation — TestTokenVerify_RejectsManipulatedPayload
und TestTokenVerify_RejectsWrongSecret: manipuliertes/falsch signiertes
Token wird abgelehnt. PASS.
3. Abgelaufenes Token erzwingt Neuanmeldung — TestTokenVerify_RejectsExpiredToken
und TestRequireAuth_BlocksWithoutValidCookie. PASS.
4. Login-Latenz mit Kostenfaktor 12 gemessen: 294ms (Ziel < 400ms) —
TestBcryptCostAgainstLatencyTarget. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
OnboardingService.Onboard: ein API-Aufruf legt Tenant (via bestehendem
Provisioner) UND ersten Administrator-Account (via IAM-01 TenantUserStore)
an. CREATE DATABASE erlaubt keine echte cross-database Transaktion, daher
Saga-Kompensation: schlaegt die Admin-Anlage nach erfolgreichem Provisioning
fehl, wird der Tenant per neuem Provisioner.Deprovision wieder vollstaendig
entfernt (Registry.Delete + DB-Drop).
Provisioner.Provision mappt Duplikat-Faelle (42P04 duplicate_database und
den bei echt parallelen CREATE DATABASE moeglichen 23505-Unique-Konflikt auf
pg_database) jetzt auf ErrTenantExists statt einer rohen Postgres-Fehlermeldung.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Onboarding-Vorgang zweimal parallel mit gleichem Slug ausgeloest —
TestOnboarding_RejectsDuplicateSlugConcurrently: genau ein Erfolg, kein
Doppel-Tenant, zweiter Aufruf bekommt ErrTenantExists. PASS.
2. Fehleingaben (leere Pflichtfelder, ungueltige E-Mail, ungueltiger Slug) —
TestOnboarding_ValidationErrors deckt alle vier Faelle mit klaren Fehlern
ab, bevor irgendein DB-Zugriff stattfindet. PASS.
3. Erfolgreicher Durchlauf von zweiter Person end-to-end nachvollzogen —
NICHT durchgefuehrt (keine zweite Person in dieser Session verfuegbar).
Offen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Benutzer-Datenmodell + CRUD fuer Tenant-User (tenant-scoped, keine
tenant_id-Spalte noetig, Tenant ergibt sich aus der DB-Verbindung, Modell C)
und getrennt dafuer SuperadminStore fuer mandantenuebergreifende Konten in
der Registry-DB — First-Class-Typ statt tenant_id-NULL-Sonderfall im
Tenant-User-Code (bekannter archivdms-Fehler vermieden).
E-Mail-Eindeutigkeit: tenant-scoped fuer normale Benutzer (UNIQUE-Constraint
gilt nur innerhalb der jeweiligen Tenant-DB), global fuer Superadmins
(eine Registry-DB, ein UNIQUE-Constraint).
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. CRUD automatisiert getestet inkl. Negativfaellen — TestTenantUserStore_CRUD
deckt doppelte E-Mail (ErrEmailTaken) und unbekannte ID ab. PASS.
2. Superadmin-Anlage ohne Tenant-Kontext — TestSuperadminStore_CreateWithoutTenantContext:
SuperadminStore.Create hat syntaktisch keinen Tenant-Parameter, kein
if-Zweig fuer "kein Tenant" im Code. PASS.
3. Datenmodell von zweiter Person gegen Dokumentation geprueft — NICHT
durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen.
Tenant-User-Handler ist im Code vorhanden, aber in cmd/core/main.go noch
nicht geroutet — braucht Connection-Routing pro Mandant (TEN-06), das nicht
Teil dieser Kachel ist. Nur der Superadmin-Endpunkt ist verdrahtet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Registry-DB (nur Tenant-Metadaten), Provisioning-Routine legt pro Mandant
eine physisch isolierte Postgres-DB an und registriert sie transaktional
(Rollback der DB bei fehlgeschlagener Registrierung). Schlanker HTTP-Handler
als Schnittstellen-Vorbereitung fuer API-01/TEN-02, kein eigenes REST-Grundgerüst.
Pruefungen:
1. Migration up/down geschrieben (0001_tenant_registry.{up,down}.sql) — nicht
gegen echte DB ausgefuehrt, da auf dieser Maschine kein Go/Postgres-Test-
Setup verfuegbar ist. Offen zur Ausfuehrung.
2. Integrationstest TestProvision_CreatesIsolatedDatabases geschrieben (zwei
Mandanten, prueft unterschiedliche db_name und current_database()) —
ebenfalls nicht ausgefuehrt, guarded per TEST_ADMIN_DSN env var. Offen.
3. Slug-Validierung (unit test TestValidateSlug) deckt SQL-Injection-Versuch
im Datenbanknamen ab — ebenfalls nicht lokal ausgefuehrt, da kein Go
Compiler auf dieser Maschine vorhanden ist. Offen.
Alle drei Pruefungen sind vorbereitet, aber NICHT durchgefuehrt worden —
zaehlen laut Vorgabe als offen bis auf einer Maschine mit Go+Postgres verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sysops