我们遇到了一个关于邀请系统的严重安全问题。我认为很容易复现。我们的网站是仅限邀请的。此外，我们在设置中勾选了“必须批准用户”。
我们的一名员工发出了一张使用次数大于 1 的邀请，因此没有限制在特定电子邮件（示例如下）。
该邀请链接传播开来，人们可以使用它进行注册。然而，我们期望当设置中勾选了“必须批准用户”时，员工必须批准任何使用这些“无电子邮件限制”邀请的人。但实际上，无论谁拥有该链接，他们都可以自动进入。因此，任何人都可以使用该链接，我们无法检查谁通过它进入。我们需要能够通过电子邮件、姓名以及我们添加的其他必填字段的组合进行“背景调查”，这些字段是我们要求在（我们检查后）批准时填写的。
这造成了一个严重的问题，因为一个来自严格禁止的外国组织的人获得了该链接并进行了注册。我不得不立即删除该帐户。这对我们来说是一个严重的漏洞。
因此，我认为“必须批准用户”的说法具有危险的误导性。目前，如果我们使用的是仅限邀请的实例，该选项就无效了。
是否有办法让员工能够批准使用未进行电子邮件限制的邀请链接的用户？当网站是仅限邀请时，这似乎是启用“必须批准用户”的逻辑方式。
我可以重现该问题，当生成批量邀请时，使用该链接注册的用户将自动豁免“必须批准用户”设置。
有人对此感兴趣吗？如果不解决，这个问题最终将导致我们组织中的 Discourse 项目停运。
我不确定这是一个错误。
阅读关于全局邀请码和绕过审批的邀请的先前主题，这很可能是按设计进行的。不过，需要团队成员对此发表评论。
@Wall-E，您在文档中看到什么让您认为未与电子邮件绑定的邀请会添加审批步骤了吗？
这里的关键是工作人员发出了邀请。Discourse 将此视为对使用邀请的用户的一种隐含批准。
如果是由非工作人员生成邀请，那么被邀请用户将进入队列等待工作人员批准。
如果使用非员工用户帐户创建邀请，那么通过该邀请进行的注册将进入审核队列吗？如果是这样，这是完全可接受的行为，@Wall-E 您可以使用一个普通的虚拟帐户来生成邀请作为一种变通方法。
我认为至少应该给管理员用户一个警告，如果他们可以选择新成员的待遇方式那就太好了。使用第二个“普通”用户将是一种糟糕的变通方法。
阅读完这个话题和之前的话题，我可以看到当前的功能是“按设计”的，但并未反映出邀请系统的最新变化。创建可供陌生人使用的邀请链接变得容易得多。现在，员工还可以危险地创建邀请链接，并将受邀者添加到可以访问网站安全类别的群组中。
@Wall-E 我很好奇，为什么你的邀请链接会落入不应被允许访问你网站的人手中。想必你的网站员工会知道要小心，不要创建可供任何人使用的邀请链接，也不要在错误的人能够使用它们的地方公开分享。在某种程度上，你面临的问题是员工培训问题。如果你的回答包含敏感的细节，请随时给我发私信。
如果当前存在任何被泄露的邀请链接，你可以删除它们，并在未来更谨慎地创建和分享新的邀请链接。作为管理员，你也可以随时在邀请页面上查看用户，了解谁兑换了他们的邀请。如果你有不信任的员工，可以将他们的权限降至 TL4，这拥有近乎版主的权限。
我认为有三种可能的行动方案：
must approve users 管理员设置的描述，使其非常清楚由管理员创建的邀请链接会绕过此设置。员工必须在所有新用户帐户允许访问网站之前批准他们。注意：员工创建的邀请会绕过此设置，无需批准。
执行（1），但当管理员创建可立即获得网站访问权限的邀请链接时，还增加一个额外的“你确定吗”的警告步骤。仅在已启用批准设置的网站上。
更改行为，使管理员创建的邀请链接像非管理员创建的邀请一样，遵守批准设置。
我同意 OP 的观点，即当前的行为具有误导性，并且有可能在已启用批准设置的网站上导致问题。启用此设置的网站会格外谨慎，需要这种额外的、偏执的控制来决定谁可以获得访问权限。
因此，我的建议是选择第三种方案——让所有邀请链接以相同的方式工作，并遵守
must approve users设置。
但我认为这不是一个错误。它是按设计运行的。重新归类为功能请求。
我也强烈支持选项 3。我正在建立一个人们可以更深入地反思情感的社区，我认为在匿名邀请链接上增加额外的审核级别（因为它们不与电子邮件地址或身份绑定）可以让我更放心地确保只有我想加入的人才会加入。
我想我可以使用邀请邮件而不是匿名邀请链接，但链接使得在 WhatsApp 或其他通讯平台上分享更加容易。
因此，我也赞成让匿名邀请链接遵守“必须批准用户”的设置。
另外，我认为如果发生 #3，那么邀请系统几乎可以作为仅限邀请论坛的申请系统。现在，我不知道如何在没有单独的 Google 表单之类的情况下让人们申请成为会员。这可以以一种方式简化它，即自定义用户字段可以作为申请表——我认为 @Wall-E 正在尝试做这件事。
我的主题不是关于那个的。我正在讨论 must_approve_users 在仅限邀请的实例中无效。启用它应该与禁用它产生不同的效果。如果没有，那么应该记录该行为不适用于仅限邀请的实例。如果我在文档中错过了它，那么这确实是我们的工作人员的责任。但如果不是，那么该功能就具有误导性，应该修复，或者至少记录下来），因为它误导了我们所有的工作人员。
请参阅上面 @david 的回复：
当然。如果文档中有说明，我可能会忽略，那么误导我的员工将是我的责任，而且警告不会有什么坏处，因为人们/员工会忘记。
是的，我看到了。已阅。
我将引用那些可能因为这个方面而关闭我们的“有权者”的话，这在我们组织中被视为一个安全问题：“如果这个系统能够允许未经授权组织的人员进入，你必须假设他们最终会这样做，无论你多么勤奋”。这正是发生的事情。“该功能”（我认为，一个非功能，因为“must_approve_user”在仅限邀请的情况下根本不起作用）已被启用，我们向我们想要邀请的正是这些人发出了无限制的邀请，显然，其中一个人与另一个组织共享了该无限制的邀请链接。
借此，我也在回答 @tobiaseigen
我们有会议、研讨会，有时会有数百名来自授权组织的人员可以加入我们的论坛。但其中一些人有时会来自其他未经授权加入我们论坛的组织（由于我们无法控制的总体政策）。
该邀请链接“失控”了，即使工作人员很勤奋，因为我们无法控制拥有该链接的“隐含授权”人员会做什么；根据定义，该链接是“无限制的”，所以他们可以将其转发给任何人。我不能因此责怪我的工作人员，因为如果你说这是“按设计”的，存在隐含的批准，这意味着这个无限制的邀请链接可以到达任何地方，因此最终会到达。这正是我们的 IT 部门负责人所谈论的，而且是有充分理由的。我们知道这一点，因此我们启用了“must_approve_users”作为我们认为是安全层的那个东西。
我看到有人在问这是功能还是错误。我不是专业程序员，这由你们决定（我是一名天体物理学家）。我仅仅是向你们报告一个给我们造成严重“问题”的事情，希望它能得到解决，以便我们能够继续使用这个出色的平台。
我完全支持选项 3，我们的研究中心和我的论坛工作人员也是如此。在另行通知之前，工作人员已被指示不要使用无限制邀请。这增加了额外的负担，因为他们现在必须添加我们想要邀请的所有人的电子邮件地址（在会议上，这超过数百名与会者……）。在每次会议、活动等场合这样做……将极大地阻碍我们的增长，我预见到一些工作人员会因为增加的工作量而离职（他们大多数是志愿者，并且在其他职责上已经超负荷）。
可以假设，如果选项 3 被采纳，将会有某种选项来匹配现有行为吗？
我们匆忙搭建的培训网站，如果没有能力为批量邀请的群组绕过审批，执行起来将困难得多。
别忘了这里也可以选择批量邀请，如果您的活动会生成包含与会者信息的 CSV 文件，您可以使用该文件直接邀请所有人。
如果不是，您也可以分享一个指向 Web 表单的 URL，以填充 CSV 文件并在那里验证用户，然后再发送批量邀请。
不幸的是，我们典型的活动无法让我们访问这些信息。这些联系人列表被主办方视为 PII（个人身份信息）。即使我们能够访问，我们也无法处理。我们需要联系一个 POC（关键联系人），而他们总是过劳（即使我们被允许访问信息），所以再次出现高粘性问题，等我们拿到邀请链接时，活动已经结束了，（我们的员工和潜在受邀者）的动力都已丧失。
知道了。这可以作为一种变通方法。但这会增加我们员工的工作量，他们本来就没有多少精力来处理这个额外的步骤。所以，这并不理想。
我很抱歉这给您和您的社区带来了一些麻烦！
今后，您知道了它的工作原理，因此可以确保您以及其他管理员和版主都能审慎地使用邀请系统！
功能与错误的争论在于优先级问题——我们试图快速修复错误，尤其是安全错误！但在此案例中，其功能与多年来保持一致，并且是按设计如此的。我认为我们应该更改它，但这并非“放下一切立即修复”类型的事情。
我们将花些时间听取其他人的意见，以便决定我们希望采取的方向。
这可能是一个更复杂的更改，具体取决于 guardian 在此过程的不同元素中的参与程度，但另一个选项（这也取决于 3）是：
must_approve_users 时在创建邀请 UI 中公开。编辑：实际上，再次查看 David 引用的代码，我认为 guardian 完全不参与决定被邀请用户是否需要被批准。看起来这部分将是简单地用类似 invite.bypass_approval? 的内容替换 invite.invited_by.staff?。
我完全理解你们在优先级方面的限制。我想我们的实例处于一种不常见的情况，因为我所知道的所有 Discourse 实例都来自那些没有严格安全策略的组织，而我们必须遵守这些策略。例如，仅限邀请是我们组织施加的限制，没有它我们的实例就无法存在。如果允许自行注册，那会更容易，我们就不需要使用可能“失控”的无限制邀请。