Row Level Security: Die unsichtbaren Mauern in der Datenbank

Was ist RLS

Row Level Security steuert Zugriff auf Zeilenebene. Nicht “User X darf auf Tabelle Y”, sondern “User X darf nur Zeilen sehen, für die die Policy true ergibt.”

Die tückische Stille

Das Gefährlichste an RLS: Kein Fehler bei Ablehnung. PostgreSQL behandelt es wie ein UPDATE, das einfach 0 Zeilen betrifft.

// Was passiert:
1. API-Key-Check: OK ✓
2. Supabase UPDATE: keine Fehler... aber 0 rows affected
3. .select().single(): "Cannot coerce the result to a single JSON object"

// Was du denkst: "Datenbankfehler?? Spalte fehlt??"
// Was wirklich passiert: RLS hat den Write stumm blockiert

Debugging-Anleitung

1. Fehler: “Cannot coerce” — Dieser Fehler bei .single() bedeutet fast immer: 0 Rows returned. Nicht 2, nicht Null — 0.
2. RLS-Policies prüfen: SELECT * FROM pg_policies WHERE tablename = 'fighters'
3. USING-Klausel lesen: Steht da is_admin()? Dann blockiert RLS den anon key!
4. Fix anwenden: SERVICE_ROLE_KEY nutzen ODER Policy auf USING (true) ändern

Schritt-für-Schritt: Den Bug debuggen

Geh den Debugging-Prozess interaktiv durch — von der API bis zur RLS-Policy:

// _cors.js
checkApiKey(req) → true

Borzsport-Lösung

Auth passiert auf API-Ebene (checkApiKey()). RLS für Writes ist damit redundant. Lösung: SUPABASE_SERVICE_ROLE_KEY + Write-Policies USING (true).