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.com/#confirmation_token=123a 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