WeWeb redirecting and adding ?_source= to url causing page to fail

So I use Supabase auth for the backend. When I send a password reset email, the url seems correct in the email:

https://gssghcfghqwrfzqxannm.supabase.co/auth/v1/verify?token={token}&type=recovery&redirect_to=https://app.carinahealth.com/confirm-new-password/

I click the link, the user gets logged in correctly with the token, then there is a redirection that seems correct, but then another immediate redirection that appends “?_source=” to the URL, causing the user to navigate to the default page / the “browser doesn’t recognize this URL, so I’ll take you here” page (which for me is the login page).

Any idea where that ?_source variable is coming from? (and how to get it to go away or otherwise get my user to route to the right page)

maybe a cloudflare issue?

eh doesnt seem like a cloudflare issue to me

Since the flow basically leaves the browser in a lost state on https://app.carinahealth.com/?_source=/confirm-new-password/

If I just manually delete the error part of the url back to https://app.carinahealth.com/confirm-new-password/ and hit go, the page correctly loads

It seems like the issue is specifically happening after the browser has already redirected to https://app.carinahealth.com/confirm-new-password/ after the supabase authentication, then app.carinahealth.com/confirm-new-password sends the browser via 302 over to /?_source=/confirm-new-password/

Mmm… I’ve never come across this error.

I think your first instinct may have been correct since the Request URL is correct.

Found this about the Miss from cloudfront in the response headers but not sure if the query string is a cause or consequence of the error :confused:

Are you sending the email with the link via Supabase directly or using a third-party tool like Sendgrid?

I’m using Resend, which is a newer setup so I assumed that would have been the issue. But since the URL is right in the email that seems confusing…

The miss from cloud front page seems interesting, but it’s a bit too technical for me to follow those steps to debug… where is cloud front introduced in this workflow? Must be under the hood on one of the tools

The issue is that your page confirm-new-password is private. So you need to be auth to access it, and when you are resetting your password, you are not. That’s why you are redirected to the page you set if the user is not logged in

This page should be public

1 Like

@Mael im not sure that’s the issue - since the url routes to supabase first to validate the token, the user comes over to weweb and is (?) authenticated. But I’ll try it out and report back

Ok it worked :slight_smile: There must be something in the sequencing / token payload that I don’t understand - it seemed risky from a security perspective to let someone change their password “before they are authenticated”

The authentication must happen right after the redirect - I have the user’s email pre-populated on the change password page, but it isn’t pre-rendered/available, it does take a split second to load the email