Login/Magic link email redirection argument/url

[laurentS]

Feature request

Is your feature request related to a problem? Please describe.

Right now, when getting a magic link or signup confirmation email, the link always sends the user to the site URL defined in the settings page. While this is great, I would like to be able to direct users to different parts of the app depending on where they are when login in/signing up.

Describe the solution you'd like

I can think of several ways of doing this.

• right now, I could add a redirect_to field in the auth.users table, set it when I trigger the magic link/signup email and read it on the other side to send the user to the right place. This means 2 db writes per login/signup (one before, one after to clear the field) and seems a bit heavy and brittle (what if there is an error just after the field is cleared? the link in the email will not work anymore)
• add an extra redirectTo parameter in the auth.signUp (or magic link) call, which would be passed on to the link in the email, and finally back to the page the user lands on (the site URL), so that the app can process this. so my siteURL could look like example.com/auth/postLogin?redirectTo=<theNextStep>

Describe alternatives you've considered

See above, I think the second option is much nicer and easier to manage (at least from my perspective 😉 )

Additional context

Add any other context or screenshots about the feature request here.

[awalias]

hey @laurentS this is a great suggestion, transferring this to the auth server repo to track it there 👍

[awalias]

also adding this requirement:

[kiwicopple]

Related on Netlify's GoTrue:

• Customize ExternalProvider Callback netlify/gotrue#262
• Reset password comes as a Mandrillapp tracking link with wrong path netlify/gotrue#112
• Document EXTERNAL_REDIRECT_URL netlify/gotrue#154

Possible fix: netlify/gotrue#149

We attempt to be intelligent and use referrer headers to try and redirect the user back to where they came from.

source

So it seems that we can add referrer to guess the redirect URL

[awalias]

we just need to test that it works with our slightly altered flow:

In netlify emails work like:

1. email sent with: <SITE_URL>#token
2. user clicks link, the application detects the token, sends a request to /verify?token= to get access_token

In supabase:

1. email sent with: <ref>.supabase.co/verify?=token (means the dev can skip step 2 above)
2. /verify will redirect the user to <SITE_URL>#access_token

[awalias]

I tested and it does indeed get passed all the way through

lets add the ability to set the referrer header ("callback_url") on the signIn() method.

we also need to decide whether to blank out referrer if the user doesn't explicitly set it -> since it can result in unpredictable behavior as per supabase/supabase#640 (or we can document this up, as the desired behavior?)

[awalias]

need to an additional query param to the email links referrer, that will inform the /verify endpoint where it needs to redirect to after verification

[laurentS]

@awalias I think you can do it one of 2 ways:

• either I call signUp(...., theFullURLToRedirectTo) and /verify redirects to it directly (or to the configured siteURL if no url passed as argument)
• or I call something like signUp(..., justAStringArgument) and then /verify redirects to the configured site URL with an arg like ?redirectTo=justAStringArgument and lets my code handle the logic as needed.

I was initially thinking of the latter, but I can't really think of any strong argument in favour of either.

[kiwicopple]

Thanks for this @laurentS - here is what we are thinking, note that this flow is if "Email Confirmations" are turned on and I think you've scoped out a flow without the Email Confirmations

1. Sign up:

const { user } = supabase.auth.signUp({
  email: 'user@email.com`
  redirectTo: 'https://some-custom-url.com/after-signup'
})

With the new redirectTo param, this function will set the referrer header (since that is what GoTrue prefers)

2. We send an email

Since we need to preserve the redirectTo param, we send a "Confirm" email to the user with the verification

Follow this link to confirm your user:

https://user-gotrue.supabase.co/v1/auth/verify?token=1234qwerty&redirect_to=https://some-custom-url.com/after-signup 

3. User confirms

After the user confirms their address then the /verify endpoint will use the redirect_to param in the URL to send the user to the right location

[laurentS]

I was thinking of a flow with email confirmation, but you've done a much better job of explaining it than I did.
It looks great to me, exactly what I'd want for my use case at least 👍
Would you add a similar flow for magic link emails? This would allow setting up entirely password-free authentication, I think.

[mcsdevv]

@kiwicopple can you expand on whether or not this will also apply to other login methods such as social?

[kiwicopple]

Confirmed - we will add this to all functionality (including password resets, magic links, etc)

[github-actions]

🎉 This issue has been resolved in version 1.4.8 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[braebo]

Glad to see this fix! Is this currently usable?

I tried: signIn({provider: 'github', redirectTo: 'http://localhost:5555/admin'}) with no luck.

[nstrelow]

I am also having problems setting redirectTo: http://localhost:3000/#/

It strips away the /#/.

@kiwicopple is this expected?

Edit: Added an issue: #90

[simonh1000]

I can see that this broadly works for the Site Url but it does not seem to work for the additional redirect urls. I want to have a variable in the redirect, so it is not possible to provide a exact url

In other words, I have success with

http://xyz.netflify.app/?invitedBy=abc
but not with
http://localhost:3000/?invitedBy=abc