Why is @supabase/auth-helpers-nextjs replaced by @supabase/ssr ?
In the old documentation we had, we used
to access an authenticated user's session
Except during the Nextjs13 conf you announced a brand new method with /ssr
I can't understand what the purpose of this change is, knowing that the old way of doing things was already ssr?
https://github.com/vercel/next.js/blob/b9dd6c4ff6b025453504c6a5669094260c23ca1b/examples/with-supabase/utils/supabase/server.ts
thank you for your help
134 Replies
Based on what I see in the repo, I believe @supabase/ssr will replace all framework-specific helper packages. So the naming is meant to be as generic as possible.
yeah I don't get it either. Apparently u import a browser client from ssr package as well?
let's see how this goes
signing in using client doesn't persist session after refreshing page using the new @supabase/ssr package
We've now added the guides for the
@supabase/ssr package, we were rushing to get these done before the talk went live but wasn't able to. The new package consolidates all the auth-helpers into one package and only exports two functions so this make it easier for us to maintain and easier for devs using it too. With the auth-helpers we had a lot of devs getting confused about the name since it had auth in it they would assume it was only meant for the auth side of stuff and then revert to using @supabase/supabase-js for all other operations which couldn't work. https://supabase.com/docs/guides/auth/server-side/creating-a-clientCreating a Supabase client for SSR | Supabase Docs
Configure Supabase client to use Cookies
Also note the
@supabase/auth-helpers-[framework] will still work and will get updates, but going forward we are pushing the @supabase/ssr package as we believe it's more flexible and cover more grounds. You can see from the guides I've linked to above that it can basically be used with any JS/Node framework while this was not possible with the auth-helpers.
It won't persist as you need to wire up cookie management in your framework yourself. Since there was no docs at the time you tried this it wasn't working.Okay I understand the idea better, thanks for the resources and the help š
Awesome! The only part I don't understand regarding the SvelteKit steps is how
data.session exists for the cookies.get method on the server-side layout load. Can you explain?
https://supabase.com/docs/guides/auth/server-side/creating-a-client?framework=sveltekit&environment=layoutHey @silentworks I just though I had finished implementing auth on my Next APP then this change suddenly appears. Can I safely continue using the
@supabase/auth-helpers-nextjs?From his comments:
Yeah, I asked the wrong thing, I can safely continue using the old package, but should I? What I will miss from not updating?
I think it's better to implement it before your project progresses further.
I'm following the new docs without success, is doing the auth but not setting the cookie for some reason
btw, I'm following the Next.js section
the cookie is being set for auth with email, not for auth with Google or Twitter, is failing with oAuth
I followed the with-supabase example by Jon, which shows how to set cookies
here is the with supabase example repo :
https://github.com/vercel/next.js/tree/ee9a13aaa0592102e229bb3e5959cebe0a7a060c/examples/with-supabase
Yeah, I was checking that example last night, is working just for email and password, I even put the oAuth for Google in the same example locally, is not working the exchangeCodeForSession because there is not cookie, the @supabase/ssr package is not creating the cookie for oAuth methods
I'm following this new docs --> https://supabase.com/docs/guides/auth/server-side/oauth-with-pkce-flow-for-ssr
OAuth with PKCE flow for SSR | Supabase Docs
Learn how to configure OAuth authentication in your server-side rendering (SSR) application to work with the PKCE flow.
TBH i haven't switched to ssr yet i m going to try it today, but it seems weird
+1, I had just migrated and am able to retrieve a valid session but am not able to create / set the cookie within NextJS following Jon's example as well. I'm not certain on how the next/headers method allows you to set / remove cookies as its a ReadOnlyRequestCookies iirc.
here is a small reproduction case, just add some envs and don't forget to enable and configure Google as provider in the dashboard
GitHub
GitHub - hipdev/with-supabase-oauth-issue
Contribute to hipdev/with-supabase-oauth-issue development by creating an account on GitHub.
I can't find any issues here, I cloned your example and entered my google credentials as you suggested
There is an issue with the size of the name and value for the cookie
In that case you need cookie chunking. I've just released
@supabase/ssr 0.0.5 with cookie chunking support but it's going to take a few days before we write some guides around using this. It's a bit weird that the same example you sent me works fine without any changes on my end.Yep, very odd, why is setting bigger cookies for me :pain:
btw, thanks for that and the quick response to the issue, I will try again then
You're welcome and thank you too for creating the reproducible example repo, it made testing the issue easier from my side.
I can see the implementation in the auth helpers - but how come is this not done transparently by the library?
+ how come the auth helpers used to work just fine without cookie chunking?
I am staring at a lot of angry customers due to oAuth fully broken - so I'd love some answers š¬
It cannot as the library know nothing to do with cookies, cookies are handled by your framework of choice, this library only provide hooks to retrieving, saving and deleting cookies.
This was never true if the cookie size was larger than the allowed browser cookie size.
How is OAuth fully broken if you are using auth-helpers?
it's very possible chunking is not the issue then. But updating the code to the new package fails to set the cookie for oAuth - for some reason
It will be a bit difficult for me to know without a reproduction like that which @JuliƔn David provided above.
I can provide it - but it's not a minimal reproduction
invited you - unfortunately it's not small
Itās highly likely cookie chunking though. We did some optimisations in the auth-helpers to reduce cookie size in earlier versions, but this too was an issue since we were maintaining how the JWT is stored in auth-helpers rather than letting gotrue-js handle that.
Received the invite. Iāll take a look shortly
I see. If we apply the same strategy as https://github.com/supabase/auth-helpers/blob/cfe4a1aefd841f9fbf845a2eba4ab5a07e4d5b2b/packages/shared/src/cookieAuthStorageAdapter.ts#L42 would that be the possible fix for this?
https://gist.github.com/Gbuomprisco/34ea48c236447a1aa1305118bc0ca217
I could paste the code you need here but I'm afraid of folks not using it correctly and we end up with more questions.
š this was my idea to make it transparent (as I see it's quite a bit of code)
That's one way of doing it, the main part we removed is the
stringifySupabaseSession as this now means you have to maintain this separately from the gotrue-js library. A case in point is if gotrue-js was to add a new attribute like session.roles your code would now need to be updated.
This would lead us back to auth-helpers which would mean we are shipping framework specific code again. This is what we are trying to avoid.I am not sure - cookieStore is a Next.js implementation passed by the consumers
Yes and you just hard coded that in the strategy, which would mean if we ship the strategy with the library we just shipped framework specific code. If this is not what you are saying then what you are showing here is more or less what we currently already ship.
No, there is no framework specific code in the strategy itself (I think)
how the cookies are parsed/set are passed by the consumers
anyhow - I'll be waiting for more on this as I don't think what I'm trying is working anyway
What you have is pretty close to what the end result will look like, Next.js is a bit weird too as it sets a cookie using either client-side or server-side code depending on if you called a method via a client component or a server component (route handler or server action).
https://github.com/vercel/nextjs-subscription-payments/blob/c7867b2d9e08d033056293d12aeb9825b8331806/app/supabase-provider.tsx
In the nextjs-subscription-payments starter template, when you replace
with the new ssr package, sign in doesn't work correctly.
It signs you in, but once you refresh page, you're no longer signed in
GitHub
nextjs-subscription-payments/app/supabase-provider.tsx at c7867b2d9...
Clone, deploy, and fully customize a SaaS subscription application with Next.js. - vercel/nextjs-subscription-payments
FWIW in my tests the chunk size was largely below the chunking threshold - so I think the issue may not be this (at least in my case)
This works again when I implement the same logic of the cookie parse/serialize methods that exist in the shared helpers but do not exist in the new package
i just realized supabase updated the docs to ssr package like 5 days ago oof
reading this thread now :')
can't get magic email sign in work, no errors but session is not stored... I use the fresh repo and exact same code from docs...
Going back to auth-helpers
actually just realized every other email works but my main email, when I use my main email to sign in logs show
{"component":"api","error":"401: invalid claim: missing sub claim","level":"info","method":"GET","msg":"401: invalid claim: missing sub claim","path":"/user","referer":"http://localhost:3000","remote_addr":"95.70.206.217","time":"2023-11-01T07:39:21Z","timestamp":"2023-11-01T07:39:21Z"}
thats strange...
after removing that user things started to work again, I guess data was corrupted š¤Æ
I just experienced same thing
I deleted user
Added back and it started working, but after 2 successful signins, it stopped working
Just spent the last 5 hours trying to transition to ssr, going back to auth-helpers
Iāll be back when they announce ssr is stable
It's supposed to be stable now š
Whatās funny is that they deprecated auth-helpers, but say that ssr is in beta and could have breaking features. But also that they recommend transitioning to ssrš
Where does it say that
Actual trolling
If Auth helpers is deprecated, and your official docs show supabase/ssr by default - it's common sense to think it's stable software
Yes, but itās not lol
Literally says in their docs ssr is in beta and is likely to have breaking changes
1. Release a preview and don't announce the deprecation of Auth helpers
2. Show the old client creation as default
I get it it says it's beta - but it's very contradictory
Google oauth is so buggy in ssr
What do u mean?
The whole oAuth is broken
Itās kind of obv itās beta. They were supposed to release it before nextjs conf, then they rushed it right after.
Yeah thatās true
The whole rushing is the issue
And they forget about docs
Like, with-Supabase example came out before the docs came out š
Docs was only added at version 0.4
Supabase is losing a ton of goodwill
So much potential
PKCE was a huge fiasco, now this
Half the API want migrated when Auth helpers suddenly switched to it
Like, I wanna make a detailed post on whatās not working, but this is just getting so frustrating, Iām just not going to. Already wasted enough time
I remember when they announced auth ui, and months later, pretty much abandoned
This is called hype driven marketing
Yep
And I'm really afraid supabase is overdoing it
Yep, I think they hired someone for marketing around last launch week as well
Marketing is no good if you can't retain customers
Iām going to have fun in a couple hours telling my client we should use the deprecated auth-helpers as weāre migrating to Supabase :hmmnice:
Lesson for me - wait a month or two before upgrading anything
My clients won the happy either lol
Itās frustrating also because weāre prob going to move to swr later as well, but need put in extra effort
I donāt even understand the justification behind ssr tbh
Oh I made it work finally
I still would like an official library release since it's way too much code in application code
Does this mean that you will store the full session and let the chunking ensure it fits?
Yes correct
Guys I'm confused as to why you don't just keep on using
auth-helpers if it's working for you. Deprecation doesn't mean EOL, I think this is what folks are misinterpreting here. And yes this package will remain beta just like how auth-helpers was and is still beta as we improve things. We suggest folks use ssr going forward but we never said auth-helpers would no longer get support. I released a new version of auth-helpers just a few days ago and continue to maintain that along with ssr. The main issue for most folks with ssr is documentation and this is something we are working on.Andrew - the Supabase Docs recommend using the SSR package, and recommend to migrate from Auth Helpers if one is using that. If I was starting to use Supabase today - my experience would be poor: the recommended way is broken. Deprecation doesn't mean EOL - but it also means use the new version: the new version is broken.
I love Supabase - but IMHO this was handled poorly
I don't think this is true from a new user's perspective. From the feedback we got this is mainly an existing user's of
auth-helpers perspective of it being broken. But I'm going to take this feedback and share with the team, we definitely could have handled this migration better, especially since it's a breaking change for anyone migrating.this comment says it all from a new user perspective
I agree with you on this. I have no arguments against this at all. We've had discussions around this internally too and are working at how to better manage breaking changes.
Thanks - this gives me reassurance
Anyway to wrap it up - I have a working version - and my clients will be back with working oAuth. Just wanted to make sure I understood the "new way" š
I'm happy to hear that and will try to get the docs as up to date as possible with the new way of doing things.
@giancarlo our hope is that long term
ssr will prove to be a better way of doing things as it will evolve easier with changes frameworks like Next.js make without us having to change how the internals of the package work again and again. I actually had the idea of shipping a few framework specific strategies for ssr as a separate npm package. But this would then leave me with the burden of maintaining these packages. It would be similar to the example code you provided yesterday.I agree with both of you, sometimes companies want to try fast the new libs and that could create mistakes, as Giancarlo is saying, the issue is with the current advice in the docs, a bit spicy at first in his comments, but he is right, also the auth helpers package works as expected, is just the communication what could be improved. Supabase is amazing and is constantly learning too, thanks for clarifying.
Just looked at this again and I must say its a brilliant way of getting this working automatically for the user. I'm going to have a chat with the team and get something going along these lines.
@giancarlo is it ok for me to DM you?
sure thing!
If u add in discord oauth as well. And try signing in using Google, then discord, it wonāt work. In auth-helpers this method worked.
I feel like ssr almost deserves it's own temp channel at this point š This post dun blown up.
I didn't expect so much enthusiasm when I asked my question š
@giancarlo
And just a few weeks ago everyone commenting on auth-helpers....
GitHub
Fix: add cookie chunking as default to ssr package by dijonmusters ...
What kind of change does this PR introduce?
Fix
What is the current behavior?
Some OAuth signin methods are failing due to size of cookie being too big
What is the new behavior?
Implements cookie c...
š¤£
Ok we just released a version with cookie chunking for
@supabase/ssr. It does it automatically for you. The only caveat is with SvelteKit, we are updating the guides now for that.Letās goooooi
Quick question, does this new package work on both app router and pages router?
Yes it does indeed. But you need to update the way how cookies are retrieved, stored and deleted for pages router setup. We have this covered in the guides too https://supabase.com/docs/guides/auth/server-side/creating-a-client?environment=get-server-side-props
Ok, so Iād just use this to make calls from the client?
Any tips for migrating to app router? Can I login from pages component client, and then access the session in the app router through a client component client?
I don't even think Next.js recommend having an app with both pages directory and app router. I think its all or nothing.
yeah, it's just that it's such a big app that migrating is going to take a while
I guess I'll have to go about a diff way migrating
this new version is the 0.0.6 right, if that's the case, is not working for me yet
Please try 0.0.7 which was just released a few minutes ago.
glad I found this discussion - I've been trying to migrate my remix project to the new ssr package. It seems more simple overall, and it is better from the point of view that it is framework agnostic. We are just missing some more documentation which I now understand is coming.
Quick question - during my implementation I can get all the way to my callback route and exchange code for session successfully and afterwards redirect to a page of my choosing.
If I'm understanding correctly, the exchangeCodeForSession method returns 'data' and 'error' objects, and the data object contains the access token of the user.
With this new package/way of working, is it from then onwards my responsibility to persist this access token as a cookie and manage deletion of this cookie on logout as well?
With this new package/way of working, is it from then onwards my responsibility to persist this access token as a cookie and manage deletion of this cookie on logout as well?This isn't correct. There is already documentation for Remix too https://supabase.com/docs/guides/auth/server-side/creating-a-client?framework=remix
thanks for your reply - I've seen these and got started following a similar approach. For some reason though, following redirect at my callback route, I can't see an access token cookie being created
Might have been due to cookie size limit, try the latest
0.0.7 release and see if its working. It also helps if you provide a minimal reproducible example repository for someone on here to check out to see what could potentially be going wrong.I'll try to update and come back with results - I can maybe work on an example tomorrow for reference. Many thanks for your help š
Hey, how are you displaying this error in your browser? Because I think I was experiencing the same issue, but i wasn't able to determine why.
Also, 0.0.7 seems to have fixed it
Thanks silentworks
Tried updating to 0.0.7 - the only cookie I can see is the auth-code-verifier cookie. The access token cookie never appears. No console errors or network tab issues
I will try to produce an example tomorrow and see if it replicates in other environments
The first time I tried with 0.0.7, I got cloudflare errors
Buggy week for the internet lol
Very buggy week. Earlier even GitHub was down too.
Wen next launch week :lets_get_into_it:
It should be every 3 months, so next month I think.
It was announced today...
...
now
issue is fixed for me with v0.0.7 :cooldoge:
Ok, so I donāt know if this is a bug, but hear me out.
The logic to handle the exchange code for session using the auth/callback routeā¦ I was able to implement that using my middleware when on auth-helpers-nextjs. This saved an additional api call being made.
The same logic doesnāt seem to be working with the new ssr package. I canāt share the repo, but I can make a reproducible demo if needed. Just lmk.
A reproducible example would be great please.
Here you go š¤
https://github.com/supabase/auth-helpers/issues/673
GitHub
@supabase/ssr middleware issue Ā· Issue #673 Ā· supabase/auth-helpers
Bug report I confirm this is a bug with Supabase, not with my own application. I confirm I have searched the Docs, GitHub Discussions, and Discord. Describe the bug When using auth-helpers-nextjs, ...
Just as an update, I fixed my issue hence why no reprod example. I was essentially passing a different Headers object to the client and at the callback route and that's why the session didn't persist. I can post a working ssr example in remix if that's helpful
Hey, I have another issue with this now. If I just return response, everything works fine. But if I do NextResponse to redirect, user isnāt signed in.
And this is why we donāt do things like this in a middleware. I will try and explain this better on your issue on GitHub and why the change I asked you to make would break the redirect.
I've observed an issue where calling a route handler from a server component results in the Supabase client not having access to cookies. This, in turn, disrupts the functionality of any APIs linked to authentication (such as RLS, getSessions, etc.). I'm wondering if this is considered a bug?
Interestingly, when using an supabase API directly within a server component, there are no issues encountered.
However, fetching a route handler from a server component seems to introduce problems.
Possibly related: https://discord.com/channels/839993398554656828/1172668357665902622
That would be awesome! Thank you š
This is just how the Fetch API works, nothing to do with the library at all. I've added how to work with this in the troubleshooting section some months ago https://github.com/orgs/supabase/discussions/15859
GitHub
Fetch requests to API endpoints aren't showing the session Ā· supaba...
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. const res = await fetch("http://localhost:3000/contac...
yes thank you i also saw this article talking about it
https://nextjs-faq.com/fetch-api-in-rsc
On the supabase docs, this is the example code for auth/callback (nextjs):
https://supabase.com/docs/guides/auth/server-side/oauth-with-pkce-flow-for-ssr
OAuth with PKCE flow for SSR | Supabase Docs
Learn how to configure OAuth authentication in your server-side rendering (SSR) application to work with the PKCE flow.
In the with-supabase template, the server client has a different method to remove cookies. Which one is the 'correct' way?
They both work.
Ok, was just wondering cuz in the starter repo, one of the commits specifically changed it from remove to set āā, wasnāt sure if there was something wrong with remove
why does the client side client creates a token as db-<Project-id>-token-code-verifier and the server side only looks for db-<project-id>-token??
@silentworks
It uses both.
The pkce auth flow sets the code verifier cookie. During verification, it's read and removed. Once a session is established, the auth token cookie is set.
maybe i was not clear
if i login in with the client browser
the token that is looked for in the server is different
in the client is saved as <something>-code-verifier
server just looks for something
yeah, I'm not understanding. You might create your own post and provide more detail.