# Supabase – Datenbank für Shuffle ## Inhalt | Pfad | Zweck | |---|---| | `migrations/` | Schema, Trigger und RLS-Policies für R1 (17 Tabellen, 2 Views). Nur additiv ändern, nie bestehende Dateien editieren. | | `tests/database/` | pgTAP-Tests: Struktur-Regeln und Zugriffsrechte je Bereich. | | `templates/` | Auth-Mailvorlagen (HTML, Go-Template) für Bestätigung und Passwort-Reset. | | `seed.sql` | Beispieldaten nur für die lokale Entwicklung. | ## Lokal starten und testen ```bash supabase start # lokales Backend supabase db reset # Migrationen + Seed einspielen supabase test db # alle pgTAP-Tests ausführen ``` ## Registrierung (KTO-01) - Der Trigger `handle_new_user` erzwingt Altersbestätigung, Zustimmung, `terms_version` und Anzeigename (1–30 Zeichen). Fehlertexte: siehe `docs/datenmodell-r1.md`. Clients senden diese Werte als `user_metadata` bei `signUp`. - pgTAP-Fixtures, die `auth.users` direkt füllen, brauchen daher `age_confirmed`, `terms_accepted`, `terms_version` und `display_name` in `raw_user_meta_data`. - Ergebnisse der GoTrue-Prüfung: `docs/specs/1-auth-spike-ergebnisse.md`. - Auth-Einstellungen (`AUTH-CFG-nn` in `config.toml`), Env-Block für Staging/Produktion, Release-Checkliste und bekannte Grenzen: [`docs/auth-konfiguration.md`](../docs/auth-konfiguration.md). - Mailvorlagen (Bestätigung, Passwort-Reset; de/en nach `user_metadata.locale`): `templates/`. Lokal landen Mails in Mailpit (`http://127.0.0.1:54324`). ## E2E-Tests (Playwright) - `e2e/` testet GoTrue über Kong (`api`), die gebaute Web-App (`web`), die IP-Drosselung (`throttle`) und den SMTP-Ausfall (`spike`). Voraussetzung: `supabase start` mit Mailpit und Postgres (Ports 54321, 54322, 54324). - `e2e/support/db.ts` verbindet sich direkt mit dem lokalen Postgres (Rolle `postgres`) und setzt `recovery_sent_at`/`confirmation_sent_at` für die Ablauftests; es bricht bei nicht-lokalem Host ab. - Der Extra-Container für `throttle`/`spike` startet mit `e2e/support/start-throttle-gotrue.sh`. Details: [`e2e/README.md`](../e2e/README.md). ## Regeln - Jede Tabelle hat `id` (uuid, PK), `created_at`, `updated_at` und Row Level Security. - `updated_at` setzt ein Trigger; `id` und `created_at` sind nach dem Anlegen unveränderlich. - Fremdschlüssel nur dort, wo Tabellen in Beziehung stehen, benannt `_id`. - Rechte werden explizit vergeben (erst alles entziehen, dann gezielt gewähren). - Admin-Rolle kommt aus `app_metadata.role = 'admin'` im JWT, nie aus `user_metadata`. ## Noch nicht enthalten - Storage-Buckets und -Policies für Avatare und Spielbilder. - Edge Functions (BGG-Import, Konto löschen). - Selbst-Hosting-Setup auf Hetzner (ADR-0002, Aufgabe für `devops`).