Signed out users can’t reset their password

[dnywh]

Signed out users who fill out the forgot password form get sent a Supabase auth email with a link to reset their password. But that link doesn’t work. It instead redirects them to sign in, which they obviously can’t do because they don’t know their current password.

Specifically, they get sent the email_action_type === "recovery" auth email with a link that looks something like this:

`${supabase_url}/auth/v1/verify?token=${token_hash}&type=${email_action_type}&redirect_to=${redirect_to}`

That unfurls to something like:

https://abc123.supabase.co/auth/v1/verify?token=pkce_abcdef12345&type=recovery&redirect_to=https://www.peels.app/auth/callback?redirect_to=/profile/reset-password

Which ultimately lands at:

https://www.peels.app/sign-in?redirect_to=%2Fprofile%2Freset-password

This redirect is almost definitely because /profile/reset-password, being in profile is a protected route and the token doesn’t seem to give them the temporary access that it should.

Note that a very similar bug occurs with email_action_type === "magiclink", which should also automatically sign the user in. It might also occur with the unused "invite" and "reauthentication" types, which have similar purposes.

That auth link is exposed in supabase/functions/_templates/reset-password-email.tsx, since we’re using custom auth emails via React Email and Resend. That’s the standard URL format for pretty much all of the Supabase auth emails, as you can see in the above docs link and elsewhere. So I don’t think the issue lies there.

I believe issue existed before I made the custom auth emails, so the problem may lie in how we handle redirects and/or protected routes. I.e. in src/utils/supabase/middleware.ts.

[dnywh]

From Mike:

...heads up about an issue I encountered with resetting my password with the Gmail app [on iOS].
I found a solution — when I changed my settings to open links in Chrome instead of Safari [the standard iOS in-app browser, not the Safari app], the password reset links started working properly. I think there might be an issue with how the reset tokens are handled when opening from Gmail to Safari.

So the problem could be with Safari. Although we’re not using Auth0, check this blog post of theirs that goes through the possible Safari issue.

From Jess:

I just tested reset password on my account and it worked fine. I was signed out, reset, hit the link from my email, changed it and was signed in. Signed out and back in all ok.

Not sure what browser just yet but she could have been on Chrome, which would reaffirm that Safari is the issue.

[dnywh]

Temporary measure on Reset Password and Magic Link emails, both of which contain the problematic {{ .ConfirmationURL }}:

<p><strong>Try using Google Chrome</strong> for the above link, if possible. Safari seems to be causing issues for some folks.</p>

[dnywh]

We should put the OTP expiry back to its normal duration once this is fixed. I've extended it slightly to make the above work-around a little less painful.