当我通过 OAuth2 SSO 注册 Discourse 账号时,我被强制使用与我用于注册的账号关联的电子邮件地址进行注册。然而,这与我使用电子邮件地址的方式背道而驰:
https://superuser.com/questions/1848533/can-e-mail-messages-be-sent-from-a-plus-address-via-thunderbird-smtp#comment2926854_1848540
截至 2026-11-01
因此(而且——无论如何——)我应该能够选择用于注册的电子邮件地址。
我之所以关心这一点,是因为我在 try.discourse.org. 上创建了许多账号, 因为:
……因此,SSO 通过预填充某些信息为我节省了一些时间。但是,如果我选择 Discourse ID,则会使用一个相当不理想的电子邮件地址,因为:
我想知道这是否与以下问题有关:
olivia
(olivia)
2
auth_overrides_email 在 try.discourse.org 上已禁用。此设置控制外部身份验证提供程序是否可以在后续登录时覆盖你的账户电子邮件。它不控制你在注册时可以使用哪个电子邮件地址。
作为一种变通方法,你可以在“偏好设置”>“账户”中更改注册后的电子邮件,并验证你首选的别名。
根据当前设置,当你再次通过 Discourse ID 登录时,你更新后的电子邮件应保持不变。
1 个赞
@olivia,谢谢。确实如此,我可以在创建账户后添加 Discourse ID SSO。但是,如果不需要这样做,将会节省我很多时间。
是的,联合登录方式会使用来自身份提供者(IdP)的元数据来创建用户账号。
对于如此小众的使用场景,我极不推荐修改核心代码(尤其是在敏感路径中)。
对你而言,我建议设置多个浏览器配置文件,每个配置文件绑定一个不同的 ID 账号。这样你就可以利用它们快速登录到 try.discourse.org。
我自己也这样做;每个配置文件在后端绑定到一个不同的电子邮件地址,而这些邮件最终都会进入同一个收件箱。
为了支持这种做法(以及其他类似技巧),我有一个特定的邮件域名,会将
LOCALPART@SUBDOMAIN.mydomain.com
重写为
realemailaddress+LOCALPART%SUBDOMAIN@mydomain.com
(或者,根据情况而定)
realemailaddress+LOCALPART@mydomain.com
如果你不想进行这样的设置,我建议你创建一个 JavaScript 浏览器书签脚本,在账号创建完成后自动为你提交邮箱更改请求。
1 个赞
@supermathie,我无法以实用的方式做到这一点,因为 Discourse ID 目前屏蔽了我的主要电子邮件域名,正如我之前提到的。因此,我被迫使用备用方案,而我并不希望直接通过该备用方案接收邮件,即使附加了子地址也不行。
这一混乱局面使得使用 Discourse ID 相当令人烦恼,因为为了避免这种情况,我必须首先手动创建账户,然后连接 Discourse ID,这样就失去了它本来可以提供的任何自动填充优势。
不过,对于任何真实账户来说,这样做也多少有些徒劳,因为启用 2FA 也会禁用所有 SSO!目前,对我来说,Discourse ID 的唯一作用就是作为单一事实来源,用于我在启用 2FA 之前已经连接到它的账户。
(即使使用其他 SSO 提供商也很麻烦,因为我力求为每个账户严格使用一个电子邮件别名。因此,即使我能够使用选定的提供商,我也希望替换选定的电子邮件地址。最终,我总是在手动创建账户后、启用 2FA 之前,再将这些 SSO 连接上来。)