|
| 1 | +--- |
| 2 | +description: Integrating with Supabase Auth. |
| 3 | +sidebar_position: 4 |
| 4 | +sidebar_label: Supabase Auth |
| 5 | +--- |
| 6 | + |
| 7 | +# Integrating With Supabase Auth |
| 8 | + |
| 9 | +[Supabase](https://supabase.com) is a comprehensive Backend-as-a-Service that offers database, authentication, and other services. |
| 10 | + |
| 11 | +To get access policies to work, ZenStack needs to be connected to the authentication system to get the user's identity. If you use Supabase as your authentication provider, this document will guide you through integrating ZenStack with it. |
| 12 | + |
| 13 | +## Syncing Supabase Auth users to your database |
| 14 | + |
| 15 | +:::info |
| 16 | +This section is only relevant if you're also using Supabase's Database service as the underlying Postgres database of ZenStack. |
| 17 | +::: |
| 18 | + |
| 19 | +Supabase Auth stores user data in a separate Postgres schema called "auth". Since that schema is managed by Supabase, it's good idea NOT to directly import it into ZModel and use it in your application. Instead, if you want to have a synchronized copy of the data, refer to [Supabase's user management documentation](https://supabase.com/docs/guides/auth/managing-user-data) for how to set up database triggers and keep your user table in sync with Supabase Auth. |
| 20 | + |
| 21 | +## Creating a user-bound ORM client |
| 22 | + |
| 23 | +Supabase provides the `@supabase/ssr` package to help with server-side authentication. Please refer to [its documentation](https://supabase.com/docs/guides/auth/server-side) for full details. The following example shows how to do it in a Next.js application. |
| 24 | + |
| 25 | +```ts |
| 26 | +import { createServerClient } from '@supabase/ssr' |
| 27 | +import { cookies } from 'next/headers' |
| 28 | +import { db } from '@/lib/db' // your ZenStackClient instance |
| 29 | +
|
| 30 | +// create a Supabase SSR client |
| 31 | +async function createSupabaseSSRClient() { |
| 32 | + const cookieStore = await cookies() |
| 33 | + return createServerClient( |
| 34 | + process.env.NEXT_PUBLIC_SUPABASE_URL!, |
| 35 | + process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!, |
| 36 | + { |
| 37 | + cookies: { |
| 38 | + getAll() { |
| 39 | + return cookieStore.getAll() |
| 40 | + }, |
| 41 | + setAll(cookiesToSet) { |
| 42 | + try { |
| 43 | + cookiesToSet.forEach(({ name, value }) => cookieStore.set(name, value)) |
| 44 | + } catch { |
| 45 | + // The `setAll` method was called from a Server Component. |
| 46 | + // This can be ignored if you have middleware refreshing |
| 47 | + // user sessions. |
| 48 | + } |
| 49 | + }, |
| 50 | + }, |
| 51 | + } |
| 52 | + ) |
| 53 | +} |
| 54 | + |
| 55 | +// create a user-bound ORM client |
| 56 | +async function getUserDb() { |
| 57 | + const supabase = await createSupabaseSSRClient(); |
| 58 | + const { data: { user } } = await supabase.auth.getUser() |
| 59 | + |
| 60 | + // you can selectively include fields into the context object |
| 61 | + // depending on what your access policies need |
| 62 | + const contextUser = user ? { id: user.id } : undefined; |
| 63 | + return db.$setAuth(contextUser); |
| 64 | +} |
| 65 | +``` |
| 66 | + |
| 67 | +:::warning |
| 68 | +It may be tempting to call the `supabase.auth.getSession()` API to get the current user. However, the data returned is not validated by Supabase's service, so it must not be trusted. |
| 69 | +::: |
| 70 | + |
| 71 | +You can then use this user-bound ORM client for CRUD operations governed by the access policies you defined in ZModel. |
0 commit comments