diff --git a/apps/docs/components/MDX/auth_helpers_faq.mdx b/apps/docs/components/MDX/auth_helpers_faq.mdx new file mode 100644 index 00000000000..0f9a289d784 --- /dev/null +++ b/apps/docs/components/MDX/auth_helpers_faq.mdx @@ -0,0 +1,31 @@ +### Fetch requests to API endpoints aren't showing the session + +You must pass along the cookie header with the fetch request in order for your API endpoint to get access to the cookie from this request. + +```ts +const res = await fetch('http://localhost/contact', { + headers: { + cookie: headers().get('cookie') as string, + }, +}) +``` + +### Performing administration tasks on the server side with the `service_role` `secret` + +By default, the auth-helpers do not permit the use of the `service_role` `secret`. This restriction is in place to prevent the accidental exposure of your `service_role` `secret` to the public. Since the auth-helpers function on both the server and client side, it becomes challenging to separate the key specifically for client-side usage. + +However, there is a solution. You can create a separate Supabase client using the `createClient` method from `@supabase/supabase-js` and provide it with the `service_role` `secret`. In a server environment, you will also need to disable certain properties to ensure proper functionality. + +By implementing this approach, you can safely utilize the `service_role` `secret` without compromising security or exposing sensitive information to the public. + +```ts +import { createClient } from '@supabase/supabase-js' + +const supabase = createClient(supabaseUrl, serviceRoleSecret, { + auth: { + persistSession: false, + autoRefreshToken: false, + detectSessionInUrl: false, + }, +}) +``` diff --git a/apps/docs/components/index.tsx b/apps/docs/components/index.tsx index 5a50214c12e..2e999d38a66 100644 --- a/apps/docs/components/index.tsx +++ b/apps/docs/components/index.tsx @@ -22,6 +22,7 @@ import QuickstartIntro from './MDX/quickstart_intro.mdx' import SocialProviderSettingsSupabase from './MDX/social_provider_settings_supabase.mdx' import SocialProviderSetup from './MDX/social_provider_setup.mdx' import StorageManagement from './MDX/storage_management.mdx' +import AuthHelpersFAQ from './MDX/auth_helpers_faq.mdx' import { CH } from '@code-hike/mdx/components' import RefHeaderSection from './reference/RefHeaderSection' @@ -74,6 +75,7 @@ const components = { SocialProviderSettingsSupabase, StepHikeCompact, StorageManagement, + AuthHelpersFAQ, Mermaid, Extensions, Alert: (props: any) => ( diff --git a/apps/docs/pages/guides/auth/auth-helpers/nextjs.mdx b/apps/docs/pages/guides/auth/auth-helpers/nextjs.mdx index 0e38a19150a..4e08a013707 100644 --- a/apps/docs/pages/guides/auth/auth-helpers/nextjs.mdx +++ b/apps/docs/pages/guides/auth/auth-helpers/nextjs.mdx @@ -79,7 +79,7 @@ NEXT_PUBLIC_SUPABASE_ANON_KEY=your-supabase-anon-key When using the Supabase client on the server, you must perform extra steps to ensure the user's auth session remains active. Since the user's session is tracked in a cookie, we need to read this cookie and update it if necessary. -In Next.js Server Components, you can read a cookie, but you can't write back to it. Middleware on the other hand, allow you to both read a write to cookies. +Next.js Server Components allow you to read a cookie but not write back to it. Middleware on the other hand allow you to both read and write to cookies. Next.js [Middleware](https://nextjs.org/docs/app/building-your-application/routing/middleware) runs immediately before each route is rendered. We'll use Middleware to refresh the user's session before loading Server Component routes. @@ -528,7 +528,7 @@ This allows for the Supabase client to be easily instantiated in the correct con