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.

[imagem] 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…

[imagem] 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

[imagem] 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 invi…

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!

Tokens de convite aceitos e transformados em ROT13

Suporte

Tópico		Respostas	Vistas
API endpoint to create invite links has moved to /invites.json Feature rest-api	17	1598	2 Dezembro , 2025
User invite process improvements Feature	26	6948	26 Junho , 2018
Optional global invite code Announcements new-feature , invites	63	30553	9 Abril , 2021
New 'accept invitation' prompt feature causing issues with invitation links Support invites	13	2455	22 Novembro , 2022
Invite tokens without email? Feature invites	8	2599	10 Março , 2018

Tokens de convite aceitos e transformados em ROT13

Related topics