参考：
新增了一个名为 invite_code 的选项设置。
设置后，所有注册账户的用户必须输入邀请码才能完成账户创建。没有该代码的用户不允许注册账户。
如果邀请码错误，用户将获得友好的错误提示：
此功能完全可选！目前仅兼容本地认证，但我们在未来的迭代中会对此进行改进。
如果启用了全局邀请码，则生效；否则不生效，且注册对话框中不会显示邀请码字段。
32 个赞
这怎么讲得通？难道代码不应该允许你绕过工作人员的新账户审批吗？
5 个赞
这段代码与员工或非员工无关，它 100% 是关于新账户注册的。
使用场景是在 WhatsApp 或 Facebook 私密群组中发布消息……
嘿，我为你搭建了一个论坛，请使用邀请码“Welcome to Discourse”注册账户。
由于该网站仅限注册访问，只有拥有该代码的人才能进入。
我们当然可以扩展此功能，但我有一个非常紧急的使用场景，因此我今天就完成了这项工作，并计划在下周进行优化。
16 个赞
我完全搞不懂这个用例是干什么的？
为什么不直接开启新账号审批，然后把人们引导到网站呢？
4 个赞
这需要手动审核每个账户。此设置对于希望用少量用户进行测试的用户，或那些将论坛访问权限作为福利开展某种促销活动的用户来说非常有用。这样的邀请代码几乎可以大幅减轻试点项目论坛的工作负担。
11 个赞
因为我需要审批每一封邮件，并且必须全天候 24/7 守在审批队列前。而我完全无法判断这个注册的随机机器人是否真的应该获得访问权限。
有了邀请码，我就至少知道他们拥有我私下分享的邀请码。
14 个赞
但这不正是“批准用户”功能的核心目的吗？
1 个赞
这也将帮助我们的 COVID-19 响应平台——是的，请尽快，万分感谢！！！！！
11 个赞
+1 支持这个功能，它对我运营的许多社区都非常有用。我理解 @codinghorror 和 @ondrej 关于上述手动审批的观点，但我觉得这填补了一个空白：介于手动邀请所有人（仅限邀请的站点）和手动审批所有人（需审批用户的站点）之间。
7 个赞
我们不想审核用户。我们只想在 Slack、Telegram 或 WhatsApp 群组中发布一个代码，让所有人使用。有时，在正式发布前让少数额外测试者参与一下也无妨。
3 个赞
是的，这个功能现在会非常有帮助！
2 个赞
我也觉得这非常有用，尤其是如果功能稍作扩展，使得能够将群组“关联”到特定的邀请码，即使用特定代码创建账户的用户会自动被添加到指定群组中。
在某些使用场景中，这或许也能解决不时被提出的关于独立于邮箱的邀请令牌的需求……
9 个赞
这与
至少他们有一个我私下分享的 URL
在本质上有什么不同呢？
因为说实话，就目前的实现方式而言，我完全无法理解这个功能。
5 个赞
在此情况下，提供输入绕过代码或管理员审批的选项最为合理。
2 个赞
我稍微喜欢这种形式的变体，只需要做一些调整。如果现在确实有紧急（？）需求，那我想也可以？
我只是个人觉得，魔法 域名 …
请在
https://forum.this-is-my-magic-domain.org注册
作为一种注册保护机制，并非完全不可用或完全无法运作，其效果不如魔法 密码 …
你必须知道秘密
this-is-my-magic-password才能访问此站点
有两种形式，我非常乐意支持：
请访问
amazing.forum.com并输入邀请码：fantastic以获取访问权限（已实现）
以及
请访问
amazing.forum.com/register?code=fantastic进行注册并获取论坛访问权限
鉴于我们通常解决此类问题的方式是将站点置于 HTTP 基本认证之后，我们可能已经超过了“100 规则”。
这两种方式非常相似，我目前先实现第 1 种，但随后会跟进第 2 种。
第 1 种的优势在于，当你不依赖复制粘贴时会更便捷，例如通过 WhatsApp 获取说明，然后在桌面上完成操作。
第 2 种的优势在于减少了输入 fantastic 的麻烦，并且更适合通过“电子邮件”分享，而非 WhatsApp 分享。
不明白这里的 forum.this-magic-domain.org 是从哪里来的吗？在这两种情况下，这都与论坛所在的域名完全相同。
10 个赞
以下是我设想的界面快速原型：
（这是在启用了 must_approve_users 的开发站点上，经过邮箱验证后的效果）
注册时以及未获批准登录时应为可选选项，因为任何强制所有用户手动复制代码的方案都可能导致问题并需要管理员介入。
不，这肯定会泄露。https://www.farsightsecurity.com/technical/passive-dns/passive-dns-faq/#q11
这种方法适用于限时设置，但不适合作为长期策略。
1 个赞
为什么在已经创建账户之后还需要批准码？
这是否意味着机器人只是注册无意义的账户，而这些账户可以在它们污染你的数据库之前就被你清除？
此外，你的账户已经注册了，可能已经通过了验证。
还有，关于“秘密域名”的讨论到底是从哪里来的？
如果我们在 Meta 上启用这个功能，例如：
请访问 meta.discourse.org 并输入代码 HELLOMETA 来创建账户。
6 个赞
我现在意识到，我无意中重复了 @codinghorror 在上一主题中提到的观点。（当时我并未阅读该内容，因为该讨论位于 #feature:announcements 频道中）
本质上，这应该是在 must_approve_users 和 login_required 的基础上进行构建，而不是创建一个完全平行的系统。当前的实现作为一种应对当前危机的权宜之计尚可接受，但后续仍需修复完善。
如果你在会议上展示这段代码，总有人可能会忘记代码细节或没有记录下来。或者，在会议视频上线后，你需要对代码进行轮换。与其费力指导他们正确地将代码复制到注册表单中，不如在你的 WhatsApp 群组里问一句“@test3 是谁的账号？”，得到肯定回复后，直接点击
这样要高效得多。（注意：这些截图是在邮箱验证之后截取的。）
1 个赞
我认为这没问题，我们只需要进行最终的微调。这里确实有一些改进我完全支持。
首先，与用户邀请页面集成。例如，如果你通过访问链接 https://meta.discourse.org/signup?u=codinghorror 在 Meta 上注册，那么在你的用户资料页上，你会显示为我邀请的人，如下所示：
请记住，基于电子邮件的邀请已经授予被邀请用户 TL1 权限……所以我们已经拥有了这项福利……查看邀请对话框……注意你也可以添加群组访问权限，而 TL 提升是隐含的。我们可能应该在此对话框的文案中明确说明这一点：
其次，你应该能够从发送邀请的同一位置生成不带电子邮件的邀请链接，如上所述 
。这完全解决了“但我不知道他们的电子邮件地址 
”的问题。
第三，我认为一个网站设为“仅限邀请”且所有邀请都以超链接加秘密密码的形式存在是完全可以的。这样一来，它就变成了：
- 你拥有的东西（例如指向网站的链接）
- 你知道的东西（例如密码
open sesame）
如果你的网站需要审批，那么秘密密码可以让你跳过审批。如果你没有审批功能，没有秘密密码就无法进入……
我的主要问题是，我们并没有与现有功能进行集成，而是通过一个晦涩的网站设置硬加了一些随机功能。但我们完全可以进行集成，使邀请功能更加完善，而不是作为一个奇怪的独立网站设置。
17 个赞