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	1701	2025年十二月2日
User invite process improvements Feature	26	7067	2018年六月26日
Optional global invite code Announcements new-feature , invites	63	31045	2021年四月9日
New 'accept invitation' prompt feature causing issues with invitation links Support invites	13	2554	2022年十一月22日
Invite tokens without email? Feature invites	8	2656	2018年三月10日

接受邀请令牌并执行 ROT13 转换

相關主題