Conversor de RLS de Supabase

El RLS de Supabase es CREATE POLICY estándar más un contexto que solo Supabase ofrece: auth.uid() y auth.jwt(), los roles anon, authenticated y service_role, y un JWT inyectado en cada petición. Esa capa de contexto, no las políticas, es lo que ata un proyecto a Supabase.

El conversor traslada toda esa capa para que tus políticas funcionen en Postgres estándar y sigan haciendo la misma autorización.

• -auth.uid(), auth.jwt(), auth.role() y auth.email() pasan a ser funciones de acceso sobre parámetros locales de la transacción, y cada claim del JWT tiene su propio parámetro.
• -TO anon y TO authenticated se convierten en predicados, y service_role en una vía de servicio que también atraviesa las políticas restrictivas.
• -Las políticas FOR ALL se dividen por comando, y los valores por defecto como default auth.uid() se reescriben.
• -El informe enumera los parámetros que tu aplicación ahora debe darle a la base de datos: tu lista de comprobación de integración.

Vanilla, la opción por defecto, es la configuración idiomática de Postgres estándar: tu app verifica a quien llama y declara hechos tipados en cada transacción (app.user_id, app.org_id). Nada en la base de datos sabe de JWT.

Compatible con Supabase es la mudanza tal cual: una capa auth.* sobre request.jwt.claims para trasladar las políticas casi sin cambios. Su vía de servicio es el rol de los claims: establece "role": "service_role" solo desde código de servidor que usaba la clave de servicio.

Ambas funcionan en CapyDB con el modelo de un solo rol: se conecta el propietario de la celda, la seguridad de filas se fuerza (FORCE) y no hace falta crear roles.

Todo lo que no se puede trasladar mecánicamente se informa, no se traduce mal:

• -Políticas que referencian auth.users: esa tabla se queda en Supabase; traslada primero las columnas que necesites.
• -Políticas sobre esquemas gestionados por Supabase, como storage y realtime.
• -Cuerpos de funciones que llaman a auth.*, junto con las políticas que dependen de ellas.
• -Funciones SECURITY DEFINER que escriben en una tabla bajo FORCE (ya no se saltan la seguridad de filas), con la solución. Las escrituras mediante EXECUTE no se detectan.

El conversor es capyrls compilado a WebAssembly. La página lo descarga una vez como archivo estático; tu SQL se lee del cuadro de texto y de los archivos que eliges, se convierte en la página y se te devuelve como descarga.

Sin cuenta, sin subida y sin registro de lo que pegas. El mismo motor funciona en la CLI si prefieres no usar el navegador.

capydb migrate rls ejecuta este conversor sobre tu repositorio o, con la máxima fidelidad, sobre la base de datos de Supabase en funcionamiento. capyrls tiene licencia MIT y funciona con cualquier Postgres de destino.

# 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