docs: Update Supabase auth example to use @supabase/ssr
#856
Conversation
…auth-helpers-nextjs` package see `https://supabase.com/docs/guides/auth/auth-helpers/nextjs?language=ts` for the recommendation from supabase
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@flixlix is attempting to deploy a commit to the next-intl Team on Vercel. A member of the Team first needs to authorize it. |
| import {createServerClient, type CookieOptions} from '@supabase/ssr'; | ||
| import {type NextRequest, NextResponse} from 'next/server'; | ||
|
|
||
| export const createClient = (request: NextRequest) => { |
There was a problem hiding this comment.
Based on the Supabase guide, I think we should accept a response here, where we can can assign cookies on directly (or if we inline this function, just use the response from the closure).
There was a problem hiding this comment.
Don't we generate our own response, which we use in the createIntlMiddleware function?
From the Supabase docs, I don't see the response argument
- Rely more on the guide from Supabase - Don't recreate the `next-intl` middleware per request - Don't wrap the Supabase client creation in a function and use `request` from the closure (as shown in their guide)
|
Hey, I took the liberty to adapt the section a bit in a780a55. I tried to make it a bit more compact by relying more on the guide from Supabase (e.g. in regard to setting up env params). Let me know if this looks good to you! |
|
|
||
| ```tsx filename="middleware.ts" | ||
| import {type NextRequest} from 'next/server'; | ||
| import {createServerClient, type CookieOptions} from '@supabase/ssr'; | ||
| import createIntlMiddleware from 'next-intl/middleware'; | ||
|
|
||
| const handleI18nRouting = createIntlMiddleware({ |
There was a problem hiding this comment.
Why put this function outside the middleware, if is not used anywhere else? Just curious
There was a problem hiding this comment.
I'd say it's really fine in either place. Since the creation of the middleware doesn't depend on any request-based information, I figured we can move it outside. But inside is absolutely ok too!
|
|
||
| ```tsx filename="middleware.ts" | ||
| import {type NextRequest} from 'next/server'; | ||
| import {createServerClient, type CookieOptions} from '@supabase/ssr'; | ||
| import createIntlMiddleware from 'next-intl/middleware'; | ||
|
|
||
| const handleI18nRouting = createIntlMiddleware({ |
There was a problem hiding this comment.
I'd say it's really fine in either place. Since the creation of the middleware doesn't depend on any request-based information, I figured we can move it outside. But inside is absolutely ok too!
amannn
changed the title
@supabase/ssr instead of the deprecated @supasebase/auth-helpers-nextjs package@supabase/ssr
|
Thank you for merging this PR! 🎉 |
created an example for usage with the new supabase ssr package. The middleware I created is working in development as well as in production. The matcher in
middleware.tsWas adapted based on multiple metadata files that needed to be ignored.Suggestions on changes are welcome.
see
https://supabase.com/docs/guides/auth/auth-helpers/nextjs?language=tsfor the recommendation from supabase.