这正是我所想的。
我将包含该主题的链接 https://meta.discourse.org/t/category-group-review-moderation/116478/1，因为我最初搜索时很难找到它。
我总是很难在 Announcements 类别中找到 #documentation。
2 个赞
老实说，无论如何这可能都是个好主意。管理员拥有所有权限（下载备份、查看/更改配置机密、查看用户的 PII、访问私人消息等），最好将这个圈子保持得很小。
在不成为完全管理员的情况下，有很多“高级特权”的空间。
2 个赞
感谢你们俩，我之前不知道这是单独的东西！
感谢您的澄清，我之前不知道是这种情况。您说得对，既然我知道了，我们肯定会限制这一点。
我已经查看了这方面的限制/要求，并已将其转达给我的团队。不幸的是，我们似乎仍然需要自行托管。您提供的 FOSS 托管非常慷慨，我们只是不符合要求。
最大的问题是页面浏览量限制。50k/月的页面浏览量对于大多数 FOSS 项目来说可能绰绰有余，但我们产生的流量远不止于此。在过去 7 天里，我们的主网站仅来自 56.47k 独立访客就产生了 187 万次总请求。我担心按照这个速度，我们很容易达到页面浏览量限制。
不过，感谢您指出这一点！
4 个赞
也许值得想办法解决这个问题。如果您知道服务器上有哪些用户是 Discourse 的员工（管理员或版主），也许可以将这些用户的 SSO 电子邮件字段设置为他们的实际电子邮件。他们拥有的任何重复电子邮件帐户都将获得虚假的电子邮件地址。
在某些情况下，员工能够从 Discourse 接收电子邮件很有用。您可能会遇到的第一个情况是，Discourse 为员工用户提供了一个 /u/admin-login 路由。该路由会显示一个接受员工电子邮件地址的表单。Discourse 会向员工发送一个一次性登录链接。这对于设置 SSO 非常方便——如果您在设置过程中意外将自己锁在站点之外，它会让您重新进入。如果您的身份验证服务器出现任何问题，它也很有用。
1 个赞
我同意，这也是我一直在思考的问题（出于 Discourse 之外的原因）。主要问题在于普通成员可以而且确实已经成为工作人员。因此，即使我们要求工作人员用户使用唯一的电子邮件地址，我们也无法保证用户拥有这些地址，当一个账户拥有重复电子邮件地址的用户成为工作人员时，这会引起问题。
话虽如此，现在已经清楚 DiscourseConnect 首先使用唯一 ID 进行用户查找，并且 DiscourseConnect 帖子中“Discourse 使用电子邮件将外部用户映射到 Discourse 用户”部分仅指将新的 SSO 用户链接到现有的 Discourse 账户，并且我对登录提示的工作方式的误解已经澄清，那么实际上有什么能阻止我们直接发送重复的电子邮件地址吗？还是这种唯一性是严格强制执行的？
是的。我在登录流程的描述中遗漏了一个步骤。Discourse 会先尝试根据 external_id 查找用户，然后尝试根据用户的 email 查找用户。如果两者都找不到，Discourse 会尝试创建用户。这就是您的用户最初在 Discourse 上注册的方式。Discourse 不允许重复的电子邮件地址，因此如果尝试使用已有的电子邮件地址创建用户，Discourse 将会抛出错误。
您需要确保在负载中发送的电子邮件对于每个用户都是唯一的。
好的，感谢您的澄清 
是否可以稍后手动更新用户的电子邮件？既然登录提示问题已经解决，我可能会考虑实施我的团队之前提出的想法，使用假电子邮件和一个我们运行的 SMTP 服务器，该服务器将这些假电子邮件映射到用户的真实电子邮件。例如，我们会将所有人的 Discourse 电子邮件更新为类似 userid@example.com 的地址，该地址首先连接到我们的 SMTP 服务器，然后获取 userid 来查找用户的真实电子邮件。不过，这需要一段时间才能准备好，所以我们需要以后能够更新用户的 Discourse 电子邮件。
可以。您需要为该设置启用 auth overrides email 站点设置。启用后，每次用户登录时，Discourse 电子邮件将与身份验证负载（在本例中为 DiscourseConnect 负载）中包含的电子邮件同步。如果未启用，用户电子邮件将在创建帐户时设置为身份验证负载中的电子邮件，但在后续登录时不会更新。
假设启用了 auth overrides email，您还可以通过向 sync_sso 路由发出 API 请求来更新它，而无需用户登录：使用 sync_sso 路由同步 DiscourseConnect 用户数据。
您也可以从站点的 Rails 控制台批量更新用户电子邮件地址，但我（认为）那样做会触发 Discourse 向用户发送确认电子邮件。这不适用于假电子邮件地址。
也许您可以先将电子邮件设置为有意义的内容。设置好 Discourse 站点后，您应该进行一些测试，看看 Discourse 会接受哪些域名的假电子邮件。根据我的记忆，我认为 @invalid.com 是可以接受的。我不确定其他域名。在您这边，您可以将类似 <userId>@invalid.com 的内容映射到用户的实际电子邮件地址。
您一直非常有帮助，非常感谢！API 解决方案正是我所想的，但知道它可以自行同步也同样完美。\n\n[quote="simon, post:28, topic:306489"]\n也许一开始您可以将电子邮件设置为有意义的内容\n[/quote]\n\n是的，我们可以。我最初打算尝试使用加号寻址（plus-addressing），这样至少一些用户一开始仍能收到电子邮件。然后稍后迁移到我们自己的 SMTP 映射服务器以支持所有人，包括那些加号寻址不起作用的人。
1 个赞
@simon @supermathie 你们到目前为止提供了极大的帮助，我希望可以稍微偏离这个话题，寻求一些后续的帮助？
我已经按照 Install Discourse for development using Docker 的指南，在本地机器上安装了 Discourse 进行测试。我似乎找不到其他关于如何为本地测试进行设置的指南？Wiki 似乎只涵盖了生产环境的设置，这需要预先设置好域名/DNS/SMTP。在我们实现所有功能之前，我们不想将论坛公开，因此我们需要一个不需要这些设置的本地测试环境。
我已经按照该指南成功运行了它，并在我们站点的本地实例上实现了 SSO，但到目前为止遇到了 2 个问题：
- 重定向到
return_sso_url似乎只起了一半作用？在我的例子中，URL 是http://localhost:3000/session/sso_login。它确实成功重定向了，但是第一次重定向后，它将我发送到http://localhost:3000，这只会显示错误RuntimeError: Discourse does not support compiling scss/sass files via Sprockets。我找到的关于这个错误的唯一一个帖子是 https://meta.discourse.org/t/error-when-building-discourse-does-not-support-compiling-scss-sass-files-via-sprockets/305402，但那个帖子似乎没有进展。发帖人没有接受任何解决方案，唯一发生的事情是询问 RAM 和交换空间大小（运行此程序的机器有 32GB RAM 和 2GB 交换空间。所以我怀疑是这个问题？） avatar_force_update似乎没有被遵守？或者至少，对于管理员用户来说不是这样？我在站点设置中启用了discourse connect overrides avatar，并在 SSO 响应负载中同时设置了avatar_url和avatar_force_update。但是，在登录管理员帐户（该帐户链接到我的外部帐户）时，它没有显示我的外部个人资料图片？通过 API 检查管理员用户的数据时，我可以看到external_avatar_url确实被正确设置了，只是它似乎没有在 UI 中使用？
这里有一个安装方法列表：https://meta.discourse.org/t/set-up-a-discourse-development-environment/182882。我有一个非 Docker 的开发站点（使用的是 Ubuntu 指南）。如果可能的话，我认为非 Docker 方法会给你带来最好的结果。我使用它的原因之一是不必处理 Discourse 和我正在开发的本地其他应用程序之间的 API 请求的网络问题。它也比 Docker 快。
应该起作用的。请确保你生成 SSO payload 的应用程序没有将布尔值 true 转换为 1。这是一个常见问题。为了解决这个问题，你可以将 SSO payload 中的任何布尔值设置为字符串 \"true\" 或 \"false\"。Discourse 会正确解析它们。首先检查一下是否是这个问题。也可能是其他问题。处理 avatar_force_update 的代码有点复杂，但可读性强：discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub
编辑：关于 SSO payload 中的布尔值问题，我想说得更准确一些，在生成 SSO payload 的过程中，环境会将布尔值 true/false 转换为字符串。Discourse 期望的字符串是 \"true\" 或 \"false\"，其他编程环境可能会以不同的方式处理它们。例如：
PHP：
wp> strval(true)
=> string(1) "1"
与 Ruby 相反：
irb(main):001> true.to_s
=> "true"
Python（我不确定 Discourse 如何处理这个）：
>>> str(True)
'True'
2 个赞
我将尝试其中一种方法。感谢您给我指明方向。不过，这相当违反直觉。通常人们会寻找 Docker 解决方案作为设置的“快速简便”方法。这是我第一次有人建议避免使用 Docker 版本。不过，这仍然引出了一个问题：为什么 Docker 版本会出现这种情况？使用另一种安装方法来绕过问题目前可行，但这并没有解决根本问题。
它肯定没有被设置为 1。我正在使用 JavaScript，布尔值 true 总是会被字符串化为字符串 \"true\"：
String(true); // 'true'
(true).toString(); // 'true'
// 这就是我的代码实际使用的
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
我以前从未接触过 Ruby，所以不确定我能深入研究多少。但乍一看，我并没有看到任何问题？然而，我已经验证了 Discourse 管理仪表板和 SSO 负载中的相关设置都已设置：
我没有测试过尝试更改标准用户帐户的头像（使其与帐户创建时的头像不同），但当我第一次登录一个标准用户帐户时，Discourse 下载了头像，并按预期应用了它。唯一没有更新的帐户是管理员帐户？
说实话，在 PHP 中，你几乎总是想使用 var_export 来获取变量的“真实”字符串表示，因为它会返回有效的 PHP 代码来重新创建该变量：
var_export(true); // true
1 个赞
请查看用户管理员页面底部的 DiscourseConnect 部分。有一个按钮可以点击，它会展开显示 Discourse 收到的最后一个 SSO payload 的值。
您也可以从 Rails 控制台找到相同的信息。例如：
>SingleSignOnRecord.last
# 或者
>SingleSignOnRecord.where(external_id: 2)
您应该启用 verbose discourse connect logging 站点设置。这会在管理员 / 日志 / 错误日志中添加一些额外的详细信息。对于头像问题，相关的日志条目可能会显示为普通的错误日志，而不是 DiscourseConnect 日志。
可能问题特定于 WordPress。它总是为 true 返回 1，为 true 的字符串表示形式返回 "1"。
1 个赞
这是预期的 payload，并且个人资料图片 URL 显示正确：
个人资料图片应该是这样的：
但它仍然显示为：
这是我的 Gravatar：
除非我误解了这个设置，或者我还需要设置其他东西，否则我已经启用了覆盖这些设置的选项：
我还尝试了在隐身模式、不同的浏览器以及清除浏览器缓存来排除缓存问题。
这是您的本地开发站点吗？
我想知道上传头像是否因某种原因失败了。请尝试启用 verbose discourse connect logging 站点设置，然后注销并重新登录。日志中应该至少有一条与头像相关的消息：
可能还会有另一条与上传失败相关的错误。
如果你还没有弄清楚，这意味着：“你必须通过 ember-cli 代理访问，而不是直接通过浏览器访问”。
使用 bin/ember-cli -u 在开发环境中启动它。
我遇到了和你一样的头像问题：
之前：
登录载荷：
之后：
但是：
我认为这是一个 bug，Discourse 正确设置了自定义头像 URL，但没有从 Gravatar 切换到自定义图片。
如果我创建一个新用户：
它会立即生效：
所以我怀疑这是由在使用 DiscourseConnect 之前已经设置了 gravatar 的帐户触发的。
2 个赞
我设法让 Ubuntu 的步骤奏效了（经过大量调整，因为安装脚本与我已安装的软件包和软件发生了冲突）。这解决了我的原始错误，但 SSO 仍然只起作用一半。现在，而不是 scss/sass 错误，SSO 每次都会给出 Account login timed out, please try logging in again.。在此错误页面上第二次单击“登录”按钮可以完成登录。我的代码没有发生任何变化，只是 Discourse 的运行方式发生了变化。
我将把这一切都归结为本地运行的怪癖。我希望生产部署不会出现同样的问题。
这似乎对 Docker 版本没有任何作用。脚本会退出，没有任何输出，并且 Discourse 方面似乎也没有真正发生任何事情。这与 Docker 指南中的步骤相矛盾，这感觉很奇怪。是否有理由在其中不提及这一点？
我觉得 Docker 方法似乎存在这些问题，并且官方建议是本地安装 Discourse（尽管安装脚本并不总是一次性奏效，因为它假定使用了 bashrc 等，并且会尝试安装已安装软件包的潜在冲突版本）？是否应该对所有可用的托管版本潜在的问题发出警告？仅仅一瞥，就不清楚该选择哪一个，通常人们会认为，如果提供了 Docker 版本，那么它应该是首选。
很高兴听到不是我一个人！
Bug 从来都不是件好事，但我很高兴能帮助找到这个 Bug。
这可能是原因，但您应该能够毫无问题地在本地运行 DiscourseConnect。您是通过 http://localhost:4200 访问 Discourse 吗？有一个奇怪的问题（在我看来），在本地开发环境中，Discourse 可以通过 localhost:4200 或 127.0.0.1:4200 访问。我建议坚持使用 localhost 域。它被视为与 127.0.0.1 不同的会话。
总之，这只是对正在发生的事情的一种猜测。请确保启用详细日志记录设置，并查看日志以获取详细信息。
安装说明应该清楚地表明您不需要运行脚本。您可以逐步执行脚本，以确保所有依赖项都已安装。
是的，我正在访问。
前面链接的说明并没有明确说明这一点。我访问了 https://meta.discourse.org/t/set-up-a-discourse-development-environment/182882，并选择了 https://meta.discourse.org/t/install-discourse-on-ubuntu-or-debian-for-development/14727，因为我正在运行 Ubuntu 22.04.3。该页面确实说明您不必运行整个脚本，但仅在指示用户运行脚本的部分之后用小字说明。
对我来说，这并不清楚，因为从上到下阅读说明的人自然会认为他们必须在继续之前完成当前步骤。所以我与安装脚本搏斗，只安装了我需要的东西，然后在我完成之后继续阅读，才看到这实际上是预期的，而且我根本不必与之搏斗。
在我看来，将该免责声明放在说明 之后 并没有使其清晰。
1 个赞
看起来它认为 nonce 不正确？现在登录时我在日志中看到这个：
无法验证 CSRF 令牌的真实性。下午 3:44
详细 SSO 日志：开始 SSO 进程 add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 下午 3:44
详细 SSO 日志：Nonce 不正确，是在不同的浏览器会话中生成的，或者已过期 add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 下午 3:44
详细 SSO 日志：开始 SSO 进程 add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 下午 3:44
详细 SSO 日志：用户已登录 PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 下午 3:44
找不到 MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb)：No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 下午 3:44
找不到 MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb)：No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 下午 3:44
进一步检查后发现，这是因为 SSO 重定向没有使用 localhost。它将我重定向回 127.0.0.1。如果我最初从使用 localhost 切换到使用 127.0.0.1，那么问题就解决了。