第一个建议是仅跟踪邀请？是的，没问题。没有令牌的用户名不应授予 TL1，因为用户名是公开信息。
我建议这些链接的格式为 https://meta.discourse.org/signup?u=codinghorror&token=3ojk6WTY，以与第一部分相呼应 
没想到这一点。文档编写会有些棘手，但这正是设置应有的交互方式。
8 个赞
没错，在这里复制 Discord 的做法没有任何坏处。我_记得_我们过去曾有过纯 URL 的邀请方式（无需邮箱），但后来因安全问题不得不将其移除。@techapj 你还记得吗？
8 个赞
是的，"无需邮箱"这一点是安全上的失误——这些邀请仍应要求邮箱验证（或通过带邮箱验证的社交登录），因为它们不会直接发送到用户的邮箱收件箱中。
5 个赞
如果目标是让分享变得尽可能简单，那么是否可以将其设计为类似推荐码的形式？这种形式易于在演示文稿、纯文本中分享，或通过口口相传。查询字符串既令人困惑又容易出错，而 domainname.tld/invite/samgdc2020 则更易于记忆且风险较低，人们可以随手记下并在传递过程中保持完整。
作为预防措施，我非常希望能看到某种形式的代码过期机制，以增加一层保护。
7 个赞
时间长度和/或使用次数是其他软件针对此类情况已实施的合理限制。而且这通常由用户自行定义。
11 个赞
确实，但查看该 PR 可以发现，整个网站只使用了一个代码。
1 个赞
是的，该功能目前仍作为插件保留：
URL 的格式如下：http://discourse.example.com/invite-token/redeem/TOKEN?username=USERNAME&email=EMAIL&name=NAME&topic=TOPICID
最基本的 URL 应为：http://discourse.example.com/invite-token/redeem/TOKEN?email=EMAIL
安全问题是，我们之前未检查提供的电子邮件地址对应的用户是否存在，但现在插件中已进行此项检查。
11 个赞
我想用户名可以默认嵌入到 token 中，或许可以通过显式指定用户来覆盖？
关于 token，我更喜欢使用 code，因为这对非技术人员来说更易懂。
我不这么认为。虽然该插件生成的 token 不包含邮箱，但它们必须通过添加邮箱才能使用，而这里的想法正是要移除这一要求，对吗？
安全问题也可以解决：
如果能实现这个功能那就太棒了。
4 个赞
这些邀请码会过期吗，还是永久有效？我们或许应该至少暂时在网站设置中为它们设定一个硬性限制？
7 个赞
GitHub - discourse/discourse-invite-tokens: Discourse Invite Tokens · GitHub 是否仍然需要一个电子邮件地址才能正常工作？也许是我误解了其工作原理。
我希望能获得一个定制的链接（无需包含电子邮件地址），以便让各组织将其发送给他们的用户。用户注册后，该链接会自动将他们分配到指定群组并引导至起始主题。这样做的原因是，我所接触的医疗机构无法或不愿共享其邮件列表，但他们愿意代表其成员发送邮件。
5 个赞
我认为您在这里的请求与 @nathank 提出的功能请求密切相关。
目前我们只有一个全局邀请码，它没有过期时间；若要使其失效，管理员只需将代码清零或更改即可。
这里所请求的是更复杂的邀请码机制，并将其集成到全局邀请系统中。
所请求的关键功能包括：
-
新的邀请链接
-
可重复使用 N 次
-
（可选）自动将用户添加到群组
-
在 M 天后过期
-
因此，在我看来，这感觉像是对该对话框的扩展：
或许可以在那里添加一个选项卡？
[批量邀请]
-
移除邮箱输入框
-
移除“发送邀请”按钮
-
添加以下内容：
允许多少人通过此链接注册？
您希望此邀请链接有效多久？默认为 1 个月。
填写完毕后，您将获得一个在限定时间内有效的邀请链接，该链接可与其他邀请系统集成，并支持将用户添加到群组等功能。
有了这些功能，我们实际上可以移除整个“邀请码”全局功能。
17 个赞
完全正确——这将完美地满足需求。
另外，如果能像“通过 CSV 批量邀请”那样，也提供一个主题帖/落地帖就更好了，这样也能保持整体的一致性。
7 个赞
如果这与当前全球局势相关，我支持优先推进这项工作，但由你决定 @sam
10 个赞
不需要，invite-tokens 不需要电子邮件地址。请参阅 Generating lots of Invite Tokens 以了解其工作原理。
8 个赞
我已经读过，但仍然感到困惑。
这似乎强烈暗示您需要用户的电子邮件地址。还是我只是太笨了？
4 个赞
我对批量邀请令牌的理解是，每个邀请对应一个令牌。这与您在此处的需求相去甚远。
我将与 @techAPJ 讨论此事。我认为高效地将用户引入新论坛在当前非常相关且重要。我们将优先改进这一流程。
9 个赞
在接受邀请时需要提供电子邮件地址，但在生成邀请令牌时不需要。
您可以将此 URL 提供给最终用户，并让他们将 EMAIL 替换为自己的电子邮件地址：http://discourse.example.com/invite-token/redeem/TOKEN?email=EMAIL。
希望这能消除您的困惑。
7 个赞
同意，这也是我非常希望看到实现的功能。
即任何拥有“邀请用户”权限的人，都能生成一个通用邀请链接，让用户加入，并被添加到邀请者的被邀请用户列表中。
按群组邀请以及设置时间或人数限制当然很好，但对我来说并非当务之急。
3 个赞
我尝试访问时收到“哎呀！该页面不存在或为私密页面”的提示。
amazing.forum.com/signup 会弹出注册模态框，但 amazing.forum.com/signup?code=fantastic 似乎未能将值传递给模态框（我也尝试过 invite_code=fantastic）。
此外，如果此功能能正常工作，最好将其添加到原始帖子（OP）中。
2 个赞