diff --git a/apps/docs/content/guides/api/using-custom-schemas.mdx b/apps/docs/content/guides/api/using-custom-schemas.mdx index ed14471b84d..f53299c0e0d 100644 --- a/apps/docs/content/guides/api/using-custom-schemas.mdx +++ b/apps/docs/content/guides/api/using-custom-schemas.mdx @@ -63,7 +63,7 @@ const { data: todos, error } = await supabase.schema('myschema').from('todos').s // Initialize the Flutter client await Supabase.initialize( url: supabaseUrl, - anonKey: supabaseKey, + publishableKey: publishableKey, postgrestOptions: const PostgrestClientOptions(schema: 'myschema'), ); final supabase = Supabase.instance.client; diff --git a/apps/docs/content/guides/database/extensions/pg_net.mdx b/apps/docs/content/guides/database/extensions/pg_net.mdx index 411437c6df8..2e3d54a6547 100644 --- a/apps/docs/content/guides/database/extensions/pg_net.mdx +++ b/apps/docs/content/guides/database/extensions/pg_net.mdx @@ -352,7 +352,7 @@ Make a POST request to a Supabase Edge Function with auth header and JSON body p select net.http_post( url:='https://project-ref.supabase.co/functions/v1/function-name', - headers:='{"Content-Type": "application/json", "Authorization": "Bearer "}'::jsonb, + headers:='{"Content-Type": "application/json", "apikey": ""}'::jsonb, body:='{"name": "pg_net"}'::jsonb ) as request_id; ``` @@ -370,7 +370,7 @@ select cron.schedule( select "net"."http_post"( -- URL of Edge function url:='https://project-ref.supabase.co/functions/v1/function-name', - headers:='{"Authorization": "Bearer "}'::jsonb, + headers:='{"apikey": ""}'::jsonb, body:='{"name": "pg_net"}'::jsonb ) as "request_id"; $$ diff --git a/apps/docs/content/guides/database/postgres/row-level-security.mdx b/apps/docs/content/guides/database/postgres/row-level-security.mdx index 387bbcabc40..3c48dd8ee4b 100644 --- a/apps/docs/content/guides/database/postgres/row-level-security.mdx +++ b/apps/docs/content/guides/database/postgres/row-level-security.mdx @@ -57,7 +57,7 @@ You can enable RLS for any table using the `enable row level security` clause: alter table "table_name" enable row level security; ``` -Once you have enabled RLS, no data will be accessible via the [API](/docs/guides/api) when using the public `anon` key, until you create policies. +Once you have enabled RLS, no data will be accessible via the [API](/docs/guides/api) when using a publishable key, until you create policies. ## Auto-enable RLS for new tables diff --git a/apps/docs/content/guides/database/secure-data.mdx b/apps/docs/content/guides/database/secure-data.mdx index 8e97333e4e1..7aadc2f7f12 100644 --- a/apps/docs/content/guides/database/secure-data.mdx +++ b/apps/docs/content/guides/database/secure-data.mdx @@ -15,7 +15,7 @@ Use Supabase client libraries, REST, or GraphQL with a publishable key. Protect ### Edge Functions -Put custom server-side logic between your client and database with [Edge Functions](/docs/guides/functions). You can use secrets, service role keys, or database connection strings inside the function, and you can [disable the Data API](/docs/guides/database/data-api#disable-the-data-api-completely) if your app only accesses data this way. +Put custom server-side logic between your client and database with [Edge Functions](/docs/guides/functions). You can use secrets, API keys, or database connection strings inside the function, and you can [disable the Data API](/docs/guides/database/data-api#disable-the-data-api-completely) if your app only accesses data this way. ### Direct database connections @@ -32,9 +32,9 @@ Your publishable key is safe to expose with RLS enabled, because row access perm Older projects may also show an `anon` key. Treat it like a publishable key: it can identify your project, but it is not a secret and must be paired with RLS and least-privilege grants. - + -Unlike your publishable key, your **service role key** is **never** safe to expose because it bypasses RLS. Only use your service role key on the backend. Treat it as a secret (for example, import it as a sensitive environment variable instead of hardcoding it). +Unlike your publishable key, your secret and service role keys are **never** safe to expose because they bypass RLS. Only use your secret and service role keys on the backend. Treat them as secrets (for example, import them as sensitive environment variables instead of hardcoding them).