Netlify-Redirects drops Netlify-Identity confirmation token (URL Hash Values)

Issue:
Netlify-Identity activation-link drops confirmation-token after site-redirects.

netlify.toml:

[[redirects]]
  from = "/"
  to = "/id/"
  status = 302
  force = true
  conditions = {Country = ["ID","MX","US"]}

See trace:

Gatsby site

Yep — I’ll corroborate this as Colin and I have been working together on his site a bit (he’s implementing my gatsby-plugin-netlify-identity-gotrue plugin that interfaces to GoTrue / Netlify Identity. The terminal above is mine too :laughing: but indeed, the confirmation token URL passed back from GoTrue via Mandrill is in the format of Example Domain and (I wonder if related to Changes to Redirects with query string parameters are coming) the #confirmation_token=123a bit is getting dropped in the redirection. Since it’s in the hash section of the URL and not technically a query-string parameter, I think it’s just getting chopped off :confused: which, in this case, where all users from the US are redirected to path-prefix /id/, means that nobody in the US, ID, or MX can actually confirm their account or execute any other token-based Netlify Identity actions :frowning:

I’ll go ahead and tag @fool in to see if he’s got any ideas on it :slight_smile:


Jon

Typically, a hash fragment is disregarded so our system won’t be able to preserve these fragments when a URL is redirected. Could you try setting an extra path as part of the confirmation URL (as shown in Identity-generated emails | Netlify Docs)? Something that won’t be redirected by one of your rules.

That said, this may be a different issue from what @jonsully mentioned since this is indeed not a query param. I do see that there is a feature enhancement request for redirecting based on a hash fragment, which I’ll this thread to. But from what we know, there may be some technical challenges in supporting this.

Thanks @Dennis, this works for now as a plausible workaround.

1 Like