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