Discourse ID 的工作原理

[Moin]

也许可以将有关更改域名后该怎么做的信息添加到第一篇帖子中：

@pmusaraj

如果您可以访问 Rails 控制台，您可以清空 discourse id 设置中的客户端 ID 和密钥，然后关闭/打开“启用 Discourse ID”设置，这将触发新的注册。

@在云端_裸奔

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[mcwumbly (Dave McClure)]

我已将以下内容添加到第一篇帖子中：

@rishabh

更改域名后重新配置 ID

更改站点域名后，要触发新的注册，您需要执行以下操作：

1. 清空 discourse id 设置的客户端 ID 和密钥
2. 切换“启用 Discourse ID”设置的关闭/开启状态。

如果您可以访问 Rails 控制台：

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[Moin]

我认为我会在第 1 步之后立即放入 rails 脚本

@rishabh

1. 清空 discourse id 设置中的客户端 ID 和密钥

这些是隐藏的站点设置，因此除了使用 Rails 控制台外，没有其他方法可以更改它们

config/site_settings.yml

[0cjs (Curt J. Sampson)]

有人能跟我们讲讲创建这个 Discourse ID 身份提供商的高层目标吗？我觉得这没什么坏处，但我想看看有没有我遗漏的优点。

在我看来，对于那些使用 GitHub、Google、Apple 或 Facebook 的人来说，创建 Discourse ID 没有任何优势，因为无论哪种方式，你都是在进行“一键”（好吧，是很少几次点击）注册或登录 Discourse 网站。那么为什么要提供这个选项呢？只是为了保持一致性吗？

为了将账户与 GitHub/Google 等分开，Discourse ID 似乎很有意义。我假设如果你使用电子邮件地址和密码进行身份验证，它会提供某种形式的双重身份验证（2FA）？

最后，Discourse ID 能与其他非 Discourse 系统一起使用吗？从技术上看，它似乎可以作为任何想要使用它的系统的身份提供商，但这是否被鼓励？不被提倡？或者 Discourse ID 可能会在某个时候中断？

我对谁在提供身份以及为什么提供身份很感兴趣，无论是出于数字主权的原因，还是仅仅为了“远离 Google/MS 等”的原因，因此了解替代身份提供商的情况对我来说非常有意义。

[pmusaraj (Penar Musaraj)]

有几个更高层次的目标，但总的来说，可以归结为两个主要优势。对于管理员来说，他们不需要配置和维护 GitHub、Google、Apple、Facebook 登录。单独来看，每个登录方式并不太难设置和维护，但需要多个步骤以及后续的维护工作。而在 Apple 的情况下，还有成本问题。

对于最终用户来说，目前并没有太大的区别。从长远来看，如果有足够的社区采用 Discourse ID，我们希望提供一个更好的集中式界面，用于管理 ID（用户加入的社区）、通知控制、用户账户自定义等。同时，还能更好地发现新社区。