集成到自定义认证系统中，邮箱不是唯一的情况？

SSO
1

我们希望将 Discourse 集成到我们现有的系统中，以摆脱对 Discord 服务器的支持。我们已经设置了自己的帐户系统，并希望尽可能重复使用它以减少摩擦。但是，在我们的情况下，电子邮件地址不需要是唯一的，只需要用户名。Discourse 似乎依赖于电子邮件是全局唯一的假设，这阻止了我们直接集成。

我查看了 DiscorseConnect，它看起来很有希望，但声明：

Discourse 使用电子邮件将外部用户映射到 Discourse 用户

这在我们的情况下不起作用，因为多个帐户可以（并且确实）使用相同的电子邮件地址。

然后我们查看了 Discourse OAuth2 Basic，乍一看它不需要电子邮件：

唯一必需的属性是 id

然而，后来它仍然提到如果 OAuth 源未提供电子邮件，则需要手动输入电子邮件地址：

请注意，我省略了电子邮件路径：SoundCloud 不提供电子邮件，因此用户在首次注册 Discourse 时必须提供并验证此信息

在我们的情况下，使用 Discourse 仍然可行吗？让用户在首次登录 Discourse 时手动提供电子邮件地址在我们看来是可以的，但前提是我们可以在实际登录过程中禁用使用电子邮件地址的功能（只需要用户名和密码），因为我们无法可靠地将电子邮件映射到唯一用户。能够完全从登录表单中禁用它将减少我们的摩擦，因为我们不会支持它，并且希望阻止用户尝试这样做。

3 个赞
2

没有太多办法。电子邮件地址必须是唯一的。

你可以做一个类似重写电子邮件的技巧，例如：

myaddress@gmail.com -> myaddrerss+username@gmail.com

这对于支持+地址的地方应该有效，大多数地方都支持。

3

我们考虑过这一点，但不确定它会如何影响 OAuth 流程，或者是否会增加注册/登录的难度。这种更改对用户来说是不可见的，因此除非他们输入修改后的电子邮件地址，否则他们将无法登录。我们当前的帐户服务器也不知道这些修改，所以即使他们输入了修改后的电子邮件，我们也无法在我们的记录中找到它？

这也会破坏已经在使用电子邮件别名的用户，不是吗？

4

真的没有好的解决方案。

除非他们使用用户名登录。

如果您允许电子邮件登录（我认为您无法使用 DiscourseConnect），如果他们收到电子邮件链接，它将正常工作。

您需要让它知道。我认为这将是第一步。

另一个糟糕的选择是只允许“第一个”（无论如何定义）用户登录 Discourse。

另一个糟糕的解决方案是强制您的系统上的用户为每个帐户获取唯一的地址。

5

……前提是他们的邮件服务器支持加号寻址；这不能保证。

1 个赞
6

是的，当然是这样，这也是我想要达到的目的。我正在寻找一种完全不允许使用电子邮件登录的解决方案，只保留用户名登录作为唯一的方法。我愿意通过完全提供来自 OAuth 服务器的虚假电子邮件来基本上完全破坏电子邮件支持（例如，没有电子邮件通知）。但这会产生摩擦，因为如果仍然可以使用电子邮件登录，用户会尝试这样做但会失败。

这实际上将迫使我们为每个用户跟踪 2 个不同的电子邮件地址，这也不理想，而且如 @supermathie 所提到的，并非所有提供商都能保证正常工作，并且仍然会产生摩擦，因为我们现在必须告诉用户他们必须记住的这个论坛特定的电子邮件地址。

是的，这在技术上是可行的。但出于显而易见的原因，这并不是一个真正的解决方案，因为它会阻止所有其他人加入论坛。

出于技术原因，我们无法做到这一点。最明显的原因是我们已经有用户拥有与其他帐户相同的电子邮件地址。但更重要的是我们根本无法做到这一点。我们希望将 Discourse 集成的项目是 Pretendo Network，这是一个针对任天堂网络的服务器仿真项目。任天堂允许其帐户系统重用电子邮件地址，因此为了准确地模拟服务器，我们也必须这样做。强制使用唯一电子邮件地址不在我们的考虑范围内。

我团队中的有人建议我们运行自己的 SMTP 服务器，该服务器负责将 Discourse 的虚假电子邮件映射到我们用户的实际电子邮件，并将从 Discourse 发送的电子邮件转发到那里。这会奏效，但显然会给我们带来更高的技术成本，并且仍然无法解决禁用电子邮件登录以及我们案例中提到的摩擦问题。

看来我们可能不得不分叉 Discourse 或使用另一个论坛解决方案来实现我们的需求。

7

我这是凭记忆说的，但你可以使用 DiscourseConnect，并使用假的但唯一的电子邮件地址。如果用户名在你这边是唯一的，那么实现起来可能很简单。电子邮件地址可以设置为类似 username@invalid.com 的值。

用户将使用他们现在正在使用的任何方法登录到你的系统。然后，你的系统将使用假的电子邮件地址生成 SSO 有效负载。

这种方法的缺点是，你需要禁用 Discourse 上的电子邮件。这可以通过将 disable emails 设置为 yes 或 non-staff 来完成（如果你的员工有唯一的电子邮件地址）。

你还可以考虑为具有重复电子邮件地址的用户使用基于 + 的电子邮件地址。我上次检查时，Discourse 认为基于 + 的电子邮件地址是唯一的。只需确保在 DiscourseConnect 有效负载中使用它们之前对电子邮件地址进行 URL 编码。这里的风险是，如果用户具有重复的电子邮件地址 并且 使用不支持基于 + 的电子邮件地址的电子邮件服务器，他们将不会收到来自 Discourse 的电子邮件，但这将允许你的其他用户收到 Discourse 电子邮件。

是的，但这仅适用于特定情况。如果用户在 Discourse 站点实施 DiscourseConnect 之前创建了 Discourse 帐户，Discourse 将尝试将现有用户与 DiscourseConnect 有效负载中的电子邮件地址关联起来。如果你正在启动一个新的 Discourse 站点，那将不是问题。

我遇到的另一个可能出现电子邮件映射问题的情况是，由于身份验证提供商站点上存在一些错误的配置，Discourse 站点上的 SSO 记录已损坏。在这种情况下，站点能够删除 Discourse 端的所有 SSO 记录，然后在用户下次登录时让 Discourse 将用户与 SSO 有效负载电子邮件地址关联起来。然后，Discourse 会为用户生成新的 SSO 记录。这仍然适用于假的电子邮件地址。

DiscourseConnect 身份验证的逻辑是，Discourse 首先尝试根据有效负载的 external_id 字段查找用户，如果找不到用户，则回退到尝试根据有效负载的 email 字段查找用户，如果仍然找不到用户，则会引发错误。

在实际在生产站点上实施之前，请仔细检查所有这些内容，但我知道在无法与 Discourse 站点共享用户真实电子邮件地址的情况下，生产站点已使用假的电子邮件方法。

8

@simon 感谢您提供的信息！这听起来我们似乎取得了一些进展。

这没问题，而且我之前也提到过，这对于“所有电子邮件都必须是唯一的”这个问题来说是一个可行的解决方案。我完全可以接受在我们的情况下基本上禁用电子邮件，并且使用虚假电子邮件是我在发帖前就想到的一个解决方案。

也许我最初没有说清楚，但发帖的目的是想看看是否有可能强制登录提示只接受用户名，因为目前登录可以使用用户名或电子邮件。如果电子邮件登录仍然显示在 Discourse 的登录提示中可用，那么我们的用户可能会尝试使用他们现有的账户电子邮件地址，但会遇到错误。所以，我们要么只能处理人们尝试使用他们当前电子邮件地址但失败的情况，要么想办法让用户意识到他们新的论坛专用电子邮件地址。这两种情况都可能导致用户混淆和不便，所以理想情况下，我们可以简单地将登录提示限制为只接受用户名。

不幸的是，员工拥有唯一的电子邮件地址也无法保证，所以我不想依赖它。这个设置是只禁用电子邮件发送吗？还是禁用整个电子邮件的使用，就像我正在寻找的登录提示那样？

我多次查看了 DiscourseConnect 页面，但没有看到这个选项。是否有更好的地方可以查看这类文档？我在那个帖子中没有看到任何指向完整文档的链接，所以我只是假设那里所有的信息就是全部了。

我承认我实际上并没有设置 DiscourseConnect 来深入研究设置。我希望文档足以让我了解可以做什么和不能做什么，这样我们就无需设置一个完整的测试实例论坛，除非我们知道我们将致力于此。但似乎仍然有一些信息不易获得，除非我错过了什么显而易见的东西？

这个在之前的讨论中也考虑过，但问题仍然是，我们要么必须处理失败的电子邮件登录，要么告诉用户这个新的论坛电子邮件地址。消除这种摩擦是我的主要目标。如果在这里无法在不修改 Discourse 本身的情况下实现这一点，而唯一的解决方案是要么处理失败的电子邮件登录，要么给人们一个新的电子邮件来记住，那么我们可能最好选择一个不同的论坛解决方案。

我似乎误解了这一点，根据帖子本身来看，这一点不是很清楚。然而，我提出这一点是为了说明对唯一电子邮件的依赖，这仍然是一个问题。

仅凭帖子，这一点绝对不清楚，除非我错过了什么。感谢您的澄清！这听起来更符合我的期望。

9

您是否已更改显示电子邮件可用于登录的文本？所有文本字符串都可以被覆盖。

如果我们还没有这样做，这将是文档的一个好范例。

如果您想使用测试站点轻松测试这些场景，可以使用例如 bratwurst

1 个赞
10

据我所知，无法强制 Discourse 登录提示只显示用户名字段。您也无法弄清楚如何让用户首先注册。这就是我建议 DiscourseConnect 的原因。

启用 DiscourseConnect 后，它将成为您 Discourse 站点的唯一身份验证系统。当用户点击 Discourse 上的登录按钮时，他们将被自动重定向到您已添加到 discourse_connect_url 站点设置中的 URL。您的身份验证系统将接管后续操作。这意味着，如果您有一个用户当前可以使用用户名和密码登录的站点，他们将继续以这种方式登录。

进行此设置需要您能够向用户当前登录的站点的后端添加一些代码。设置并不难。您可以在此处找到一个很好的示例代码：https://github.com/discourse/wp-discourse/blob/main/lib/sso-provider/discourse-sso.php。您也可以在此论坛上获得一些帮助。

如果无法向您当前的站点添加代码，您也可以创建一个小型网站，用户可以使用用户名和密码登录，然后将 DiscourseConnect 代码添加到该网站。这比分支 Discourse 要省事。

2 个赞
11

谢谢！看来我对 DiscourseConnect 有根本性的误解。我一直以为登录页面保留在 Discourse 上，它只是连接到外部服务器。我不知道用户会被完全重定向到我们选择的另一个登录页面。

我对 DiscourseConnect 的误解似乎是导致此问题和所有混乱的关键。

2 个赞
12

如果你不关心 Discourse 发送电子邮件进行通知，那么你可以让你的 SSO 将 game-username@bogus.invalid 作为电子邮件地址提供给 Discourse。

这样用户或许就可以添加第二个真实电子邮件地址，然后将假的电子邮件地址切换为次要的。

13

抱歉，我昨晚没有看到您的回复

我还没有。就像我之前说的，在我们知道 Discourse 可用之前，我们不想进行测试部署。所以实际上我还没有尝试过任何事情，到目前为止，我们只是在阅读你们的功能，并在不清楚的地方在这里提问。听到这个消息真是太好了，我不知道我们能控制到什么程度。

老实说，除了 API 之外，似乎很难找到任何实际的文档。至少从第一次使用的角度来看。

Discourse 主页上没有任何明显链接到任何文档的内容，DiscourseConnect 页面上的所有链接要么链接到不相关的页面，要么链接回帖子本身。尝试在搜索引擎上搜索“Discourse 文档”只会 dẫn đến 页面，例如 https://meta.discourse.org/c/documentation/10，这只是它的论坛类别，而不是真正的文档页面，以及 https://docs.discourse.org/，但这是 API 文档，似乎没有任何关于 DiscourseConnect 等功能的内容。

尝试有机地找到这些信息已被证明是困难的。

我是否遗漏了某个明显的地方，所有这些信息都在那里？似乎我找到的最接近的是论坛类别，因为那里有许多由工作人员和其他人撰写的关于各种主题的指南/操作方法。但是，我不太确定是否应该重复使用论坛来记录它本身？像 Discourse API 一样，是否有专门针对 Discourse 功能/工具的文档来源？

14

是的，这样可行。正如之前多次提到的，在发帖之前我们就已经考虑过使用来自 oauth 提供商的虚假电子邮件地址了。

但这本身并不能解决“如果用户在登录提示中看到电子邮件被接受，他们就会尝试使用它们，但由于电子邮件是假的而失败”的问题。

然而，我之前对 DiscourseConnect 的工作方式存在误解。我原以为登录表单仍在 Discourse 中，而 Discourse 只是联系了 oauth 提供商。@simon 已经纠正了我的这个想法，我不知道它实际上会将用户转移到我们自己的登录表单。仅此一点就解决了我的几乎所有问题。不过，还是谢谢你！

1 个赞
15

即使您只想试用一下，并且不打算继续使用我们的托管服务，也请随时启动一个试用站点！我们不介意！

感谢您的反馈——我们正在有意识地努力改进这一点。

如果您不介意，我们可以与您联系以进一步讨论吗？

2 个赞
16

与我共事过的人，没有人对 discourse.org 的托管服务感到不满意。如果您因为某些原因需要自行托管，可以登录 https://dashboard.literatecomputing.com/ 加入“免费试用”组，然后免费使用仪表板（如果您无法弄清楚如何加入免费试用组，那么您可能需要比我愿意提供的更多的支持）。如果您愿意使用 Digital Ocean 和 mailgun，只需输入 API 密钥和主机名即可。

17

我可耻地甚至没有想到这个选项！这是一个很好的观点，我们很可能会为了测试目的而采纳它。

我今天早些时候看过你们的托管选项，因为这比自托管要容易，但不幸的是，这似乎大大超出了我们的预算。我们有超过 200,000 名用户，所以“基础”计划不是一个选项。我们有 5 名以上的员工，所以“标准”计划也不是一个选项。而且，作为一个 FOSS 项目，我们依靠捐赠运作，勉强够支付一位全职开发者的费用，所以“商业”计划是遥不可及的。

不过，将试用用于测试目的是一个绝妙的主意，谢谢！我们已经自托管了我们的大部分服务，甚至包括我们的 Mastodon 实例，所以自托管 Discourse 并不是一个巨大的障碍。

当然！如果我能帮上忙，我总是乐于助人，即使只是提供一些反馈。我希望我的话听起来不太负面，因为我的本意并非如此，请明确。

18

如果您有兴趣，我们为一些 FOSS 项目提供免费托管……您的员工人数超过了我们的限制，但做出决定的那些人或许能够对此网开一面。

（请注意，我们这里对“员工”的定义是“管理员”+“全站版主”，而不是“各自公司的员工”——我很想知道您之前对员工的定义是什么）

并没有，这很礼貌也很合理 :+1:t3:

1 个赞
19

谢谢！我之前没注意到你们的定价页面上有这个。我刚回去仔细查看了一下，它藏在页面底部很深的地方 :sweat_smile: 我会仔细看看这个，然后和我的同事们商量一下！

在这种情况下，我们对“员工”的定义涵盖了两个主要角色：

  • 我们核心开发团队的成员（作为一个开源项目，这个人数可能会有所波动，因为人们可能会来来去去，但多年来我们任何时候都有约 5-10 名活跃的开发人员）
  • 我们的版主团队（非开发人员和社区成员，他们负责管理我们的服务，例如在线比赛和我们的 Miiverse 实现，以及我们的 Discord 服务器）。这个人数也会变化。

我们可以将人数限制在 5 名开发人员以内，这样就可以满足限制条件，但这将需要我们决定谁拥有论坛的完全访问权限，谁没有。这也将限制能够管理论坛的人数（我们引入了一个独立于开发团队的版主团队，以便将这个负担从我们身上卸下来）。

我一定会和我的同事们讨论这件事，看看结果如何！

20

我觉得 TL4/分类版主可以在这里提供很多帮助。

2 个赞