TLDR: Anti-virus software / Email client URL checking-bot is likely to blame.
We’ve experienced strange behavior with three of our sites, that results in the user not being able to use the invite link we sent them—and in an account being created without the user’s knowledge. Adding to the confusion the account that’s created is a ROT13 transformation of the user’s name, email, and username.
I’ve got a hunch as to why this is, but haven’t been able to confirm it yet. I’m posting it here for anyone else who might be experiencing the same issue.
Here’s the detailed scoop:
We’re on hosted Discourse installs. We’re using the discourse-invite-tokens plugin and a custom script to generate the invite links. The script makes a HTTP request to the "{}/invites/link API endpoint to get the invite token by passing the user’s email address and group_name, and then returns the invite token. The invite token is combined with our site url and the user’s name, username, and email address.
A sample invite link looks like this:
https://oursite.com/invite-token/redeem/fd9b913dc5eeba4e80d27ee765709a25?username=loislane&email=lois@example.com&name=Lois%20Lane
It’s a one-time use invite link. When a user clicks on it an account is created for them and they’re logged in to Discourse for the first time (we have a private Discourse that you can only see if you log in). This triggers Discourse to send the Account Created email.
However, with the users in question, when they click on the link they’re taken to the login page. That’s the first strange thing because normally when you try clicking a link that’s already been used you get a plain text JSON response in the browser that says:
{"success":false,"message":"Your invite token is invalid. Please contact the site's administrator."}
But the users who have had the issue uniformly report that clicking the link redirects them to the main url of our site (and since they’re not logged in) which shows them the login screen.
From the admin side, we notice that a new user has been created with a gibberish name (points to the Discourse team for helping us realize that the gibberish was actually a ROT13 translation of the the user’s email). https://www.rot13.com/ is a quick resource for checking ROT13 text.
In this example instead of a user named loislane we found a user with the username ybvfynar. The ROT13 transformation affects the user’s email, username, and real name fields (but not the group we assigned them to because the group name is baked into the invite token not displayed as a query string parameter).
One of the clues that finally lead us down the right track was that the query string parameter’s values were mangled while the parameter’s keys weren’t garbled.
Which lead to this: email - Mangled URL Parameters in IE9 - Stack Overflow
Which lead me to a new search on meta which lead to this: https://meta.discourse.org/t/invite-system-automatically-joining-people/39493/8?u=alxpck
We don’t really have a way around this yet, so we’re just recreating the invites for people who experience the problem. It’s not a terrible pain because it’s such a low percentage 0.5% of users affected, but it was a pattern we couldn’t explain until now (and we’re still guessing). If our users are all able to identify the same anti-virus or email client watchdog we might be able to do something proactive going forward. If I find out more I’ll update this post with details.
If you’re in the same situation, I hope this helps.
Thanks to @simon, @techAPJ, @codinghorror, and the rest of the Discourse team for helping us deal with the issue.
UPDATE: What’s the cause?
- One of the three users has this stack: IBM Note Mail Client, Symantech, and both Firefox/Chrome.
