Supabase-RLS-Konverter

Supabase-RLS ist normales CREATE POLICY plus ein Kontext, den nur Supabase liefert: auth.uid() und auth.jwt(), die Rollen anon, authenticated und service_role und ein JWT in jeder Anfrage. Diese Kontextschicht, nicht die Policies, hält ein Projekt bei Supabase fest.

Der Konverter verlegt die ganze Schicht, sodass deine Policies auf reinem Postgres laufen und weiter dieselbe Autorisierung leisten.

• -auth.uid(), auth.jwt(), auth.role() und auth.email() werden zu Accessor-Funktionen über transaktionslokale Einstellungen; jeder JWT-Claim bekommt eine eigene Einstellung.
• -TO anon und TO authenticated werden zu Prädikaten, service_role wird zu einem Service-Pfad, der auch restriktive Policies passiert.
• -FOR-ALL-Policies werden pro Befehl aufgeteilt, Spalten-Defaults wie default auth.uid() werden umgeschrieben.
• -Der Bericht nennt die Einstellungen, die deine Anwendung der Datenbank jetzt schuldet – deine Integrations-Checkliste.

Vanilla, der Standard, ist das übliche Setup für reines Postgres: Deine App prüft den Aufrufer und setzt pro Transaktion typisierte Fakten (app.user_id, app.org_id). Nichts in der Datenbank weiß von JWTs.

Supabase-kompatibel ist der direkte Umzug: ein auth.*-Shim über request.jwt.claims, sodass Policies fast wörtlich übernommen werden. Der Service-Pfad ist die Rolle in den Claims: Setze "role": "service_role" nur aus Servercode, der den Service-Key verwendet hat.

Beide laufen auf CapyDB mit dem Modell mit einer Rolle: Der Eigentümer der Zelle verbindet sich, Row-Level-Security wird per FORCE erzwungen, und es müssen keine Rollen angelegt werden.

Alles, was sich nicht mechanisch übertragen lässt, wird gemeldet statt falsch übersetzt:

• -Policies, die auf auth.users verweisen – diese Tabelle bleibt bei Supabase; übertrage zuerst die Spalten, die du brauchst.
• -Policies auf von Supabase verwalteten Schemas wie storage und realtime.
• -Funktionsrümpfe, die auth.* aufrufen, zusammen mit den Policies, die davon abhängen.
• -SECURITY-DEFINER-Funktionen, die in eine Tabelle unter FORCE schreiben – sie umgehen Row-Level-Security nicht mehr –, samt Lösung. Schreibzugriffe über EXECUTE werden nicht erkannt.

Der Konverter ist capyrls, kompiliert zu WebAssembly. Die Seite lädt ihn einmal als statische Datei; dein SQL wird aus dem Textfeld und aus den gewählten Dateien gelesen, in der Seite konvertiert und dir als Download zurückgegeben.

Kein Konto, kein Upload, kein Protokoll dessen, was du einfügst. Dieselbe Engine läuft auch im CLI, falls du ganz ohne Browser arbeiten willst.

capydb migrate rls führt diesen Konverter gegen dein Repository aus oder, am genauesten, gegen die laufende Supabase-Datenbank. capyrls steht unter MIT-Lizenz und funktioniert mit jedem Postgres als Ziel.

# from your repo (finds supabase/migrations) or straight from the live database
$ capydb migrate rls
$ capydb migrate rls --source-url "$SUPABASE_DIRECT_URL" --uid-type text

# standalone, MIT, any Postgres
$ go install github.com/capydatabase/capyrls/cmd/capyrls@latest
$ capyrls convert supabase/migrations