Closed vehm closed 2 months ago
If you look in the auth-js code, the resetPasswordForEmail
method is setting a code verifier, and the docs mention using exchangeCodeForSession
; however, I don't know how to setup the email template to have the link include the code
. Right now, my email template is setup for tokens with /auth/confirm. I'm not sure how that's working with SSR 0.3.0, but it seems we're supposed to be sending it to /auth/callback instead? Or maybe the docs are wrong, idk.
Even when it's working with 0.3.0, the code verifier cookie just sits in the browser, since it never gets used.
https://github.com/supabase/auth-js/blob/master/src/GoTrueClient.ts#L1635
I fixed mine. Instead of using type=recovery
in the template, use type=email
. Still using /auth/confirm with the token hash. However, it seems the lingering code verifier and docs need addressed. Or maybe my "fix" is just a hack, and something else needs done to be able to use the callback route and exchangeCodeForSession method.
I fixed mine. Instead of using
type=recovery
in the template, usetype=email
. Still using /auth/confirm with the token hash. However, it seems the lingering code verifier and docs need addressed. Or maybe my "fix" is just a hack, and something else needs done to be able to use the callback route and exchangeCodeForSession method.
I think for the time being I'm going to downgrade to 0.3.0, but changing the type like you said does work as I would expect. I haven't delved into the actual code behind SSR 0.4.0, but it's interesting that this only seems to fail with type=recovery
.
I will help out with this however I can, so if this gets any visibility from anyone, please let me know what I can do to help out -whether it's updating the docs or anything else.
It took me forever to figure out why this is happening.
The verifyOtp
method in auth-js will fire either a PASSWORD_RECOVERY or SIGNED_IN event if it successfully creates a session. Typically this is the latter. However, in the case of the recovery
type, passed into verifyOtp
, it fires the former. You can see this here
However, the new ssr 0.4.0 code does not look for the PASSWORD_RECOVERY event in it's onAuthStateChange
function; so even though it sees there are changes for storage to process, it never calls await applyServerStorage
. You can see this here.
So, the solution is to add || event === "PASSWORD_RECOVERY"
as an additional event check in the ssr code.
UPDATE: I created a PR to fix.
Nice catch @j4w8n , just noticed yesterday that my reset password flow is no longer working
@hf any chance we can merge the fix? This is affecting our prod env
Bug report
Describe the bug
Password Recovery flow does not work as expected for
@supabase/ssr
v0.4.0, whereas the same code works for v0.3.0. Confirmations, invitations, and magic links seem to work just fine, but password recovery does not. It does not update the session if the type is set to "recovery".To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
{{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=recovery&next=/change-password
@supabase/ssr
is v0.4.0@supabase/ssr
to v0.3.0Expected behavior
The password recovery flow for v0.4.0 of
@supabase/ssr
, as detailed here, should authenticate the user and redirect them to the "/change-password" page.System information
Additional context
I followed these guides: https://supabase.com/docs/guides/auth/server-side/sveltekit https://supabase.com/docs/guides/auth/passwords?queryGroups=flow&flow=pkce&queryGroups=framework&framework=sveltekit#resetting-a-password
A reference repo using v0.3.0 I used to confirm that the code worked, but updating it to v0.4.0 fails: https://github.com/j4w8n/sveltekit-supabase-ssr