我们有一个私有站点，其特点如下：
我们拥有一个大型邮件订阅列表，希望将列表中的所有电子邮件地址“预先批准”。如果某人访问站点并尝试使用与我们预先批准列表中的电子邮件关联的 Facebook 或 Google 账户进行注册或登录，则无需等待工作人员审批，即可立即开始使用站点。
理想情况下，我们还希望能够根据电子邮件预先配置群组成员资格。
这是否可行？欢迎提供需要调用 Discourse API 的解决方案。
恐怕这根本行不通！
主要是因为在未启用本地登录的情况下，邀请功能无法使用。因此，您可能需要一个非常定制化的插件来处理所有这些功能，或者需要一个外部认证系统来满足您的要求。
欢迎，Steve！
我认为，如果你通过导入脚本获取地址，系统会正确执行。你需要确保这些用户未被标记为活跃状态，除非你希望冒给他们发送大量通知和摘要的风险。
这在控制台中应该相对容易实现。如果你托管在某处，我认为也可以通过 API 来完成。
“Large”具体指的是什么？
“Large” 指的是大约 5,000 个用户——数量多到我们不希望在 UI 中手动输入。
@pfaffman 能否请您进一步说明一下如何通过 API 创建用户？看起来创建用户时“密码”是必填字段，我猜如果禁用了本地登录，这应该无法完成：POST /users
再补充一下使用场景，供其他可能有类似考虑的人参考：我们希望鼓励用户使用社交账号登录——我们致力于让许多人参与 Discourse，但他们中许多人不熟悉技术，我们希望他们知道无需再管理另一个用户名和密码。
然而，Discourse 当前的“通过邮件邀请”功能要求用户设置密码，这与我们为用户简化流程的目标相悖。
是否有其他方式可以实现我们的目标？如果必要，我们并不排斥启用本地登录，但我们希望被邀请的用户能清楚地看到他们可以通过社交账号登录，完全无需密码。
谢谢大家！我非常期待让更多人使用 Discourse。
允许他们不创建密码，同时强制要求他们告知你在使用社交登录时所用的电子邮件地址，这并不是一回事。如果他们使用社交登录，仍然可以选择不设置密码。我经常拒绝使用我的 Gmail 账户登录（尽管现在这种情况少了一些），我的妻子也几乎总是拒绝这样做。此外，通过电子邮件登录非常便捷，意味着你根本不需要密码。不过我扯远了。
如果 API 要求提供密码，只需生成一个随机密码即可。拥有一个你既不知道也不需要使用的密码，基本上等同于没有密码。
我得承认，直到仔细查看我才意识到，对于接受邮件邀请的用户来说，密码字段是可选的。你提出的观点很中肯：用户应该能够选择是否使用不同的邮箱并创建密码。如果界面能更清楚地表明密码是可选的，尤其是当网站启用了社交登录时，我会放心得多。以当前的界面来看，除非用户真的不想设置密码，否则很难发现这并非强制要求，在我看来。我想我应该卷起袖子，提交一个 PR 来改善用户体验 
我查看了示例代码，谢谢！顺便提一下，我需要使用这个变通方法来调用相应的 API：Using the API to create a user on an SSO only system - #13 by DylannCordel - 即便如此，我认为这仍不符合我设想的用例，因为它会向用户发送激活邮件，而我原本希望避免这种情况，以便在他们最终登录网站时获得无缝的“即插即用”体验。
我还尝试了这个方案：How to manually add user in discourse? - #10 - 我认为可以通过这种方法“黑客”式地添加我需要的用户账户，但最终我不确定直接修改容器内的环境来进行这些操作是否值得冒这个风险。
总之，我认为我所期望的工作流程目前并不是一个受支持或预期的工作流程，在界面得到改进（也许）之前，我只能接受这一点。
谢谢大家！
你这里把几件不同的事情搞混了。
社交登录会跳过密码设置，因为认证是由 Facebook、Twitter、Google 等第三方处理的。
邀请链接会让密码暂时变为可选，但你必须再次点击邀请链接才能“登录”。我认为我们对这一流程的限制过于严格，导致实际上已经无法正常工作。之后你需要通过邮箱提交密码重置请求才能进入，而这又要求你设置一个密码。
说来话长，但邀请功能的设计初衷是让用户能够以最少的麻烦尽快加入并回复，但它并不是为了让用户永远跳过设置密码这一步。
目前看来，以下流程是可行的：
诚然，这可能本就不应该可行，而我之前关于界面不清晰的评论，实际上可能是一个特性而非缺陷，旨在阻止用户使用这种变通方法。不过，对于通过电子邮件被邀请但最终不想创建密码、更倾向于使用社交登录其他优势（例如同步头像）的用户来说，这似乎仍是一条可行的路径。
我完全理解之前的观点，即有些用户确实希望使用密码而不是社交登录，我也确信不应为那些希望使用密码的用户禁用该功能。不过，我仍然希望能为那些偏好不使用密码的用户，提供一条简单清晰的邀请或设置路径。
该路径没有问题，但请记住，无密码的情况只是暂时的，原因如前所述。
因此，无论如何用户都需要进行“某些操作”，不存在完全无密码的永久状态。
有道理。最终用户需要创建密码或关联其社交媒体账号。谢谢！
如果您满意使用电子邮件登录（或社交账号登录），则无需设置密码。