Password Recovery Does Not Update Auth Session

[vehm]

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

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:

1. Set up SvelteKit SSR client as detailed here.
2. Create Forgot + Change Password pages as detailed here.
3. Update the Password Recovery email template to use the following template:
   {{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=recovery&next=/change-password
4. Ensure that the version of @supabase/ssr is v0.4.0
5. Attempt to reset password for a user through their email.
6. When the user visits the reset link, authentication fails.
7. Change the version of @supabase/ssr to v0.3.0
8. Try the password reset flow again.
9. It works.

Expected 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

• Supabase SSR: 0.4.0

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

[j4w8n]

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

[j4w8n]

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.

[vehm]

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 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.

[j4w8n]

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.

[cipriancaba]

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