Convertisseur RLS Supabase

Le RLS de Supabase, c'est du CREATE POLICY standard plus un contexte que seul Supabase fournit : auth.uid() et auth.jwt(), les rôles anon, authenticated et service_role, et un JWT injecté dans chaque requête. C'est cette couche de contexte, pas les politiques, qui retient un projet chez Supabase.

Le convertisseur déplace toute cette couche : vos politiques tournent sur Postgres standard et continuent d'assurer la même autorisation.

• -auth.uid(), auth.jwt(), auth.role() et auth.email() deviennent des fonctions d'accès sur des paramètres locaux à la transaction, chaque claim JWT ayant son propre paramètre.
• -TO anon et TO authenticated deviennent des prédicats, et service_role devient un chemin de service qui franchit aussi les politiques restrictives.
• -Les politiques FOR ALL sont scindées par commande, et les valeurs par défaut comme default auth.uid() sont réécrites.
• -Le rapport liste les paramètres que votre application doit désormais fournir à la base : votre liste de contrôle d'intégration.

Vanilla, le mode par défaut, est la configuration idiomatique de Postgres standard : votre application vérifie l'appelant et déclare des faits typés à chaque transaction (app.user_id, app.org_id). Rien dans la base ne connaît les JWT.

Compatible Supabase, c'est le déménagement à l'identique : une couche auth.* sur request.jwt.claims, pour reprendre les politiques presque telles quelles. Son chemin de service est le rôle des claims : ne définissez "role": "service_role" que depuis du code serveur qui utilisait la clé de service.

Les deux fonctionnent sur CapyDB avec le modèle à rôle unique : le propriétaire de la cellule se connecte, la sécurité des lignes est imposée (FORCE), et aucun rôle n'est à créer.

Tout ce qui ne se transpose pas mécaniquement est signalé, pas mal traduit :

• -Les politiques qui référencent auth.users : cette table reste chez Supabase ; reprenez d'abord les colonnes dont vous avez besoin.
• -Les politiques sur les schémas gérés par Supabase, comme storage et realtime.
• -Les corps de fonctions qui appellent auth.*, avec les politiques qui en dépendent.
• -Les fonctions SECURITY DEFINER qui écrivent dans une table sous FORCE (elles ne contournent plus la sécurité des lignes), avec le correctif. Les écritures via EXECUTE ne sont pas détectées.

Le convertisseur est capyrls, compilé en WebAssembly. La page le télécharge une fois comme fichier statique ; votre SQL est lu depuis la zone de texte et les fichiers que vous choisissez, converti dans la page, puis proposé en téléchargement.

Pas de compte, pas d'envoi, aucune journalisation de ce que vous collez. Le même moteur tourne dans la CLI si vous préférez vous passer du navigateur.

capydb migrate rls exécute ce convertisseur sur votre dépôt ou, de la façon la plus fidèle, sur la base Supabase en production. capyrls est sous licence MIT et fonctionne avec n'importe quel Postgres de destination.

# 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