Confirmation emails forward to /, no way to set redirect URL, widget must be loaded in root?

[braco]

It looks like there are three issues that I see users bring up from time to time:

1. Confirmation emails don't honor their page origin and will forward users to site root
2. There's no way to set the redirect URL manually
3. Therefor the widget needs to be loaded on the site's root or on every page?

This is bad for the enduser's UX and borders on hacky for the developer. I went down this rabbit hole trying to protect one route with content in Netlify (via _redirects and roles), and it seems like the task keeps growing, and at this point it seems like it would be better to not use Identity at all.

I see blame for these issues passed back to gotrue-js, is there a PR that I could develop that would help these issues? I'm not really clear on why this feature is difficult to implement.

It would be amazing if Netlify provided a button decorator / HTML attribute for simple use cases like this.

<a href="/protected_page" netlify_login />This prompts for auth and forwards to page on success</a>

_redirects

/protected_page/* 200! Role=user
/protected_page/ /protected_page_login 401!

[futuregerald]

Hi @braco, you can create your own custom e-mail templates with URL's to any pages on your site. We pass some variables in that you can use to pass the token in to your custom URL. As long as the netlify-identity-widget is loaded on the page that people are sent to, it will pull the token from the URL and confirm the user. You can read more about this in our docs: https://www.netlify.com/docs/identity/#identity-generated-emails

[futuregerald]

@braco I read your question a bit quickly. Can you tell me a bit more about the difficulty you had with setting up redirects? Also is the site that you are setting this up on currently on a Business Team?

[braco]

@futuregerald: quick Q first, could this be set as an ENV variable on Netlify?

https://github.com/netlify/gotrue/blob/master/conf/configuration.go#L197

[abtx]

Hi, I'm having similar issue. I'm using react router as in this example , and when I register, regardless of what url I set up in custom email link, I get to login screen when I follow the confirmation link although the widget shows the user is logged in.

[philwolstenholme]

The widget is currently 70kb so we really don't want to have to load it on the homepage/root of our site if that page doesn't actually have anything that requires Identity on it.

It'd be super nice if we could specify what URL a user should be redirected back to after using the widget.

I only have one protected route (at the moment) so I was able to get around this issue by adding the code below to my homepage, but it's not a great user experience as the user has to wait for the homepage JS to download and execute before they are then redirected to another page.

if (
  document.location.hash.includes("access_token") &&
  document.location.hash.includes("token_type") &&
  document.location.hash.includes("expires_in") &&
  document.location.hash.includes("refresh_token")
) {
  const redirectUrl = "https://example.com/my-protected-route/";
  window.location = redirectUrl + document.location.hash;
}

You could probably also add document.referrer === 'https://mydomain.com' into that long list of conditions too.

[aentwist]

Note that this

you can create your own custom e-mail templates with URL's

is no longer possible on the Netlify free plan (~ October 2021).

Thus, as the free Netlify service currently is, the email template URLs are not customizable and must point to root.

---

I am not sure if I am facing the issues raised here, but I am trying to get around the combination of the limitation mentioned above and this

widget must be loaded in root

by deploying Identity on one site (and that's it) and deploying the actual site on another URL.

Flow from the "auth site" (my-site.netlify.app) to the "real site" (my-site.com) is kinda working, using a snippet provided by Decap CMS - essentially on login do location = subdirectory of real site. There could even be simpler ways to do this, which I will explore if I can fix the below.

Flow the other way isn't going well. I am not yet even sure whether there will be security limitations. The requests from the widget on the subdirectory of the real site seem to use absolute paths to make requests and do not allow for a custom domain. i.e. GET /.netlify/identity/settings is GET https://my-site.com/.netlify/identity/settings but for starters I need that to be GET https://my-site.netlify.app/.netlify/identity/settings (use a domain other than current).

The whole value proposition here almost converted me completely from Cloudflare to Netlify for this project, but due to the lack of customization offered by Netlify as described here, that is not the case. The "real site" is Cloudflare Pages :)

I'm going to keep working this over by investigating the JavaScript API provided... and probably working on some custom modifications. Hopefully I am able to get somewhere. This is code I can see and work on myself whether I am heard or not; the Netlify code is not so, therefore I have no hopes of being able to affect it in any way within a reasonable amount of time.