Supabase RLS
Supabase tables and storage buckets must be explicitly exposed.
- Grant schema and table privileges intentionally.
- Revoke public default table and sequence privileges from Data API roles.
- Revoke Sanmopia table access from
anonunless a contract explicitly names public read access. - Enable RLS before user-facing access.
- For UPDATE access, provide both SELECT visibility and UPDATE
USING/WITH CHECKpolicies. - Add RLS policies as database safety rails, not as Sanmopia RBAC authority.
- Do not use Supabase
app_metadata, profilemember_rolecolumns, or RLS policy predicates as application RBAC/ReBAC authority. - Supabase session/app metadata may carry non-authoritative identity hints only; backend APIs must re-check business actions through SpiceDB and, where needed, OPA.
- Supabase stores identity, business rows, audit rows, storage grants, and relationship facts for sync/replay.
- SpiceDB owns RBAC/ReBAC permission evaluation for application actions such as reservation view, charge finalization, care delivery recording, caregiver payout, branch settlement, HQ review, and finance close.
- Branch membership rows must sync into SpiceDB relationships through the
sanmopia_spicedb_relationshipsqueue payload before operator APIs trust them. - Keep private storage bucket access under SQL-managed policies with SELECT, INSERT, and UPDATE for upsert.
- Keep Supabase client access in adapters.