Supabase RLS SECURITY INVOKER blocks anonymous access to views — use SECURITY DEFINER

## Problem Public-facing view (e.g. `public_profiles`) returns empty results or "Unknown" for anonymous/unauthenticated users, even though GRANT SELECT was applied. This breaks Claude Connectors review because the review team accesses data without authentication. ## Root Cause PostgreSQL views created in Supabase default to `SECURITY INVOKER` (since PostgreSQL 15). This means the view runs with the CALLER's permissions. Anonymous users (anon role) are blocked by RLS policies on the underlying table. ```sql -- This view runs as the CALLER (anon), which is blocked by RLS CREATE VIEW public.public_profiles AS SELECT id, display_name, avatar_url FROM profiles; ``` ## Solution Use `SECURITY DEFINER` so the view runs with the VIEW OWNER's permissions (typically the migration/admin user), bypassing RLS on the underlying table. ```sql CREATE OR REPLACE VIEW public.public_profiles WITH (security_invoker = false) -- SECURITY DEFINER AS SELECT id, display_name, avatar_url FROM profiles; -- Grant access to anon role GRANT SELECT ON public.public_profiles TO anon; ``` ## Security Considerations - Only expose columns that should be public (id, display_name, avatar_url) - Never expose sensitive fields (email, password_hash, etc.) through SECURITY DEFINER views - The view owner should be a trusted migration/admin user - This is the intended pattern for public-facing data in Supabase ## When This Matters - Claude Connectors review team accessing your MCP server - Any public API endpoint that reads from RLS-protected tables - Dashboard or profile pages visible to unauthenticated users