Conversor de RLS do Supabase

O RLS do Supabase é CREATE POLICY padrão mais um contexto que só o Supabase oferece: auth.uid() e auth.jwt(), os papéis anon, authenticated e service_role e um JWT injetado em cada requisição. É essa camada de contexto, não as políticas, que prende um projeto ao Supabase.

O conversor transfere a camada inteira para que suas políticas rodem em Postgres puro e continuem fazendo a mesma autorização.

• -auth.uid(), auth.jwt(), auth.role() e auth.email() viram funções de acesso sobre configurações locais da transação, e cada claim do JWT ganha sua própria configuração.
• -TO anon e TO authenticated viram predicados, e service_role vira uma via de serviço que também passa pelas políticas restritivas.
• -Políticas FOR ALL são divididas por comando, e valores padrão como default auth.uid() são reescritos.
• -O relatório lista as configurações que sua aplicação agora deve ao banco: seu checklist de integração.

Vanilla, o padrão, é a configuração idiomática de Postgres puro: seu app verifica quem chama e declara fatos tipados a cada transação (app.user_id, app.org_id). Nada no banco sabe de JWTs.

Compatível com Supabase é a mudança direta: uma camada auth.* sobre request.jwt.claims, para levar as políticas quase sem alterações. A via de serviço é o papel nos claims: defina "role": "service_role" apenas em código de servidor que usava a chave de serviço.

Os dois rodam no CapyDB com o modelo de papel único: o dono da célula se conecta, a segurança de linhas é forçada (FORCE) e nenhum papel precisa ser criado.

Tudo o que não pode ser transferido mecanicamente é informado, não traduzido errado:

• -Políticas que referenciam auth.users: essa tabela fica no Supabase; leve antes as colunas de que você precisa.
• -Políticas em schemas gerenciados pelo Supabase, como storage e realtime.
• -Corpos de funções que chamam auth.*, junto com as políticas que dependem delas.
• -Funções SECURITY DEFINER que escrevem em uma tabela sob FORCE (elas deixam de contornar a segurança de linhas), com a correção. Escritas via EXECUTE não são detectadas.

O conversor é o capyrls compilado para WebAssembly. A página o baixa uma vez como arquivo estático; seu SQL é lido da caixa de texto e dos arquivos que você escolhe, convertido na página e devolvido como download.

Sem conta, sem envio, sem registro do que você cola. O mesmo motor roda na CLI se você preferir não usar o navegador.

capydb migrate rls executa este conversor no seu repositório ou, com mais fidelidade, no banco Supabase em produção. O capyrls tem licença MIT e funciona com qualquer 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