You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Executing `handleAuth()` creates the following route handlers under the hood that perform different parts of the authentication flow:
58
-
59
-
-`/api/auth/callback`: The `UserProvider` forwards the session details here every time `onAuthStateChange` fires on the client side. This is needed to set up the cookies for your application so that SSR works seamlessly.
60
-
61
-
-`/api/auth/user`: You can fetch user profile information in JSON format.
62
-
63
-
-`/api/auth/logout`: Your Next.js application logs out the user. You can optionally pass a `returnTo` parameter to return to a custom relative URL after logout, eg `/api/auth/logout?returnTo=/login`. This will overwrite the logout `returnTo` option specified `handleAuth()`
64
-
65
45
Wrap your `pages/_app.js` component with the `UserProvider` component:
@@ -83,15 +79,16 @@ You can now determine if a user is authenticated by checking that the `user` obj
83
79
84
80
## Client-side data fetching with RLS
85
81
86
-
For [row level security](https://supabase.com/docs/learn/auth-deep-dive/auth-row-level-security) to work properly when fetching data client-side, you need to make sure to import the `{ supabaseClient }` from `# @supabase/auth-helpers-nextjs` and only run your query once the user is defined client-side in the `useUser()` hook:
82
+
For [row level security](https://supabase.com/docs/learn/auth-deep-dive/auth-row-level-security) to work properly when fetching data client-side, you need to make sure to use the `supabaseClient` from the `useSessionContext` hook and only run your query once the user is defined client-side in the `useUser()` hook:
@@ -273,20 +271,24 @@ If you visit `/api/protected-route` without a valid session cookie, you will get
273
271
274
272
## Protecting routes with [Nextjs Middleware](https://nextjs.org/docs/middleware)
275
273
276
-
As an alternative to protecting individual pages using `getServerSideProps` with `withPageAuth`, `withMiddlewareAuth` can be used from inside a `_middleware` file to protect an entire directory. In the following example, all requests to `/protected/*` will check whether a user is signed in, if successful the request will be forwarded to the destination route, otherwise the user will be redirected to `/login` (defaults to: `/`) with a 307 Temporary Redirect response status:
274
+
As an alternative to protecting individual pages using `getServerSideProps` with `withPageAuth`, `withMiddlewareAuth` can be used from inside a `middleware` file to protect the entire directory or those that match the config object. In the following example, all requests to `/middleware-protected/*` will check whether a user is signed in, if successful the request will be forwarded to the destination route, otherwise the user will be redirected to `/login` (defaults to: `/`) with a 307 Temporary Redirect response status:
277
275
278
276
```ts
279
-
// pages/protected/_middleware.ts
280
-
import { withMiddlewareAuth } from '@supabase/auth-helpers-nextjs/middleware';
277
+
// middleware.ts
278
+
import { withMiddlewareAuth } from '@supabase/auth-helpers-nextjs';
It is also possible to add finer granularity based on the user logged in. I.e. you can specify a promise to determine if a specific user has permission or not.
286
288
287
289
```ts
288
-
// pages/protected/_middleware.ts
289
-
import { withMiddlewareAuth } from '@supabase/auth-helpers-nextjs/dist/middleware';
290
+
// middleware.ts
291
+
import { withMiddlewareAuth } from '@supabase/auth-helpers-nextjs';
0 commit comments