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…

Added a simple confirmation button via: https://github.com/discourse/discourse-invite-tokens/commit/f2f1fdddbdce9a5bf709d55030628489caaf90e7 [40] Also, added a check to verify that the email provided is valid.

[image] alxpck: 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 Just add a parameter called ‘ok’ with value ‘ok’ to all requests and check if it’s still ‘ok’ when it’s received.

Interesting solution… But what if the ROT13 translation is happening in a way that’s not visible to the users? That’s what we believe is happening. Because when they forward the email to us the link looks correct. When they look at it, the link looks correct. Our assumption is that the anti-virus…

[image] alxpck: Our user will see the right email in the params and would see “ok” in the params, but since the link was one use only it’s already used up. It’s not about the users looking at the link - my solution is that the system will not use up the link if the ‘ok’ parameter is bad, but …

Ahh… gotcha. In this case “the system” is a Discourse hosted install. We don’t have access to what the server is doing when the links are used. @simon is something like what @michaeld described possible?

Hmm @techAPJ a GET request should never redeem an invite, we should require one more click here, is that not the case? Then the easy fix is just say not valid if the email address has no @ in it, plus it would not be redeemed anyway

[image] sam: we should require one more click here, is that not the case? Yes, that is not the case for invite tokens (requires plugin: discourse-invite-tokens ). I agree we should require at least an additional click, if possible a full-blown accept invite page like we have for regular invit…

Two things: a ROT13 email address still has an @ in it, so in our case that wouldn’t be a useful lookup we’re specifically using the invite plugin BECAUSE it doesn’t have an invite page. The ability to take our paid users directly into Discourse with a username of our choosing (their first and…

I think a minimal “extra click” here is a good minimal hurdle (can be a minimal page with … click here to accept invite), especially since some email clients like pre-fetching links and so on. Creating resources on GET is a big no-no.

Great. We’re totally on-board for a minimal page. We just don’t want to introduce any cognitive load to the process on this intermediary page so a “I accept the invite” button is vastly preferable to a form they need to fill out. Thank you!

Invite tokens accepted and ROT13 transformed

Support

Topic		Replies	Views
API endpoint to create invite links has moved to /invites.json Feature rest-api	17	1535	December 2, 2025
User invite process improvements Feature	26	6880	June 26, 2018
Optional global invite code Announcements new-feature , invites	63	30102	April 9, 2021
New 'accept invitation' prompt feature causing issues with invitation links Support invites	13	2411	November 22, 2022
Invite tokens without email? Feature invites	8	2575	March 10, 2018

Invite tokens accepted and ROT13 transformed

Related topics