Supabase RLS 변환기

Supabase RLS는 표준 CREATE POLICY에 Supabase만 제공하는 컨텍스트를 더한 것입니다. auth.uid()와 auth.jwt(), anon·authenticated·service_role 역할, 그리고 모든 요청에 주입되는 JWT입니다. 프로젝트를 Supabase에 묶어 두는 것은 정책이 아니라 이 컨텍스트 계층입니다.

변환기는 이 계층 전체를 옮겨, 정책이 순수 Postgres에서 실행되며 같은 권한 부여를 계속하게 합니다.

• -auth.uid(), auth.jwt(), auth.role(), auth.email()은 트랜잭션 로컬 설정을 읽는 접근자 함수가 되고, JWT 클레임은 각각 독립된 설정이 됩니다.
• -TO anon과 TO authenticated는 조건식이 되고, service_role은 제한 정책도 통과하는 서비스 경로가 됩니다.
• -FOR ALL 정책은 명령별로 나뉘고, default auth.uid() 같은 열 기본값은 다시 작성됩니다.
• -보고서에는 애플리케이션이 이제 데이터베이스에 제공해야 할 설정이 나옵니다. 이것이 통합 체크리스트입니다.

기본값인 Vanilla는 순수 Postgres다운 구성입니다. 앱이 호출자를 검증하고 트랜잭션마다 타입이 있는 사실(app.user_id, app.org_id)을 설정합니다. 데이터베이스는 JWT에 대해 아무것도 모릅니다.

Supabase 호환은 그대로 옮기는 방식입니다. request.jwt.claims를 읽는 auth.* 심 덕분에 정책을 거의 그대로 옮길 수 있습니다. 서비스 경로는 클레임의 role입니다. "role": "service_role"은 서비스 키를 쓰던 서버 코드에서만 설정하세요.

두 방식 모두 CapyDB에서는 단일 역할 모델로 동작합니다. 셀의 소유자가 접속하고, 행 보안을 FORCE하며, 역할을 만들 필요가 없습니다.

기계적으로 옮길 수 없는 것은 잘못 변환하지 않고 보고합니다.

• -auth.users를 참조하는 정책. 이 테이블은 Supabase에 남으므로 필요한 열을 먼저 옮기세요.
• -storage, realtime 등 Supabase가 관리하는 스키마의 정책.
• -auth.*를 호출하는 함수 본문과 그에 의존하는 정책.
• -FORCE된 테이블에 쓰는 SECURITY DEFINER 함수(더 이상 행 보안을 우회하지 못함)와 해결 방법. EXECUTE를 통한 쓰기는 감지하지 못합니다.

변환기는 WebAssembly로 컴파일한 capyrls입니다. 페이지는 이를 정적 파일로 한 번만 내려받습니다. SQL은 텍스트 상자와 선택한 파일에서 읽혀 페이지 안에서 변환되고, 다운로드로 돌려받습니다.

계정도, 업로드도, 붙여 넣은 내용의 기록도 없습니다. 브라우저를 쓰고 싶지 않다면 같은 엔진이 CLI에서도 동작합니다.

capydb migrate rls는 이 변환기를 저장소에 대해, 가장 정확하게는 실행 중인 Supabase 데이터베이스에 대해 실행합니다. capyrls는 MIT 라이선스이며 어떤 Postgres를 대상으로도 동작합니다.

# 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