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
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 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 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
I’ll go ahead and tag @fool in to see if he’s got any ideas on it
–
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.