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.

[画像] 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…

[画像] 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 ign…

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

[画像] 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 invites …

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!

招待トークンの受け付けとROT13変換が完了しました

サポート

トピック		返信	表示
API endpoint to create invite links has moved to /invites.json Feature rest-api	17	1588	2025 年 12 月 2 日
User invite process improvements Feature	26	6936	2018 年 6 月 26 日
Optional global invite code Announcements new-feature , invites	63	30441	2021 年 4 月 9 日
New 'accept invitation' prompt feature causing issues with invitation links Support invites	13	2450	2022 年 11 月 22 日
Invite tokens without email? Feature invites	8	2597	2018 年 3 月 10 日

招待トークンの受け付けとROT13変換が完了しました

関連トピック