如果用户已找到其账户（即知道其 username 和 id），但不知道密码（且未添加如 CTAP2 之类的单因素身份验证方法），他们无法仅通过在相关个人资料 URI 后附加 .json 来获取该账户的电子邮件地址。
因此，考虑到密码重置表单需要电子邮件地址，而不接受用户名，他们该如何请求重置密码？
他们可以在各个电子邮件账户中搜索论坛域名吗？他们有多少个电子邮件地址？
如果其他方法都行不通……
- 向管理员发送一份可能的电子邮件地址列表以供验证（管理员可以向正确的地址发送电子邮件，这样比较安全）
- 询问管理员是否愿意发送一个部分隐藏的版本，例如
a**********t@*****.com？有时候这就足以提供帮助（但这也会泄露少量信息，所以他们可能不愿意）
工作人员可以看到用户注册时使用的电子邮件地址。工作人员可以告知用户其电子邮件地址，以便用户登录。
电子邮件无法在 JSON 中查看。事实上，即使对工作人员来说，它也被隐藏得很好（即位于“显示”按钮后面），并且据我回忆，会被记录到工作人员日志中。
这是否可行？
@awesomerobot 和 @NateDhaliwal，这些方法的问题在于，我最近在 community.openAI.com 上遇到了这种情况，因为我使用了电子邮件别名服务，如今很多人都这么做。不过，如果仅仅是使用了子地址（sub-addressing）形式的电子邮件地址，情况会更糟，因为这种做法很常见，但很难记住。[1] 不幸的是，像许多 Discourse 实例一样，这里没有提供联系管理员的途径，这也是另一个问题。
如果无法找回我的电子邮件地址，我就真的没办法了。
不过，它是接受用户名的。
第一个表单字段提示输入电子邮件或用户名。
第一个字段下方的链接无论您输入的是电子邮件还是用户名都能正常工作。
我忘记了密码 链接同样适用于用户名或电子邮件，除非管理员启用了 隐藏电子邮件地址已被占用 站点设置。
在 OpenAI 网站上，忘记密码表单要求输入电子邮件，但在禁用该设置的其他网站上，表单允许输入用户名：
所以，除非我误解了您的需求，否则听起来我们目前已经支持您所请求的功能。
@southpaw，所以接受用户名进行密码重置是一个偏好设置，而他们将其禁用了？我问这个是因为我在那里观察到的是：
如果是这样，也许应该更清楚地说明，例如：
此 Discourse 实例已禁用基于用户名的密码重置。
不过，我在这里也观察到了相同的情况：
我不明白为什么你提交的截图中的表单与我在这里观察到的似乎有所不同。
我相信你会同意，防止他人获取你的电子邮件地址必须是网站的首要任务。为此，管理员可以选择启用一项网站设置，通过拒绝向试图猜测电子邮件地址的人提供提示，从而提供额外的保护层，直到他们看到确认已找到已注册地址的消息。该网站设置的一个副作用是，忘记密码表单不会接受用户名输入。
我给出的例子来自一个禁用了该特定设置的网站。
你给出的两个例子来自启用了该特定设置的网站。
这就是你观察到差异的原因。
我很好奇，除了表单字段不接受用户名这一事实之外，这些额外信息如何能让你更轻松地恢复账户？
@southpaw，我对此感到惊讶，因为大多数网站通过不指示密码请求是否成功来绕过这个问题。相反，用户输入电子邮件地址或用户名，如果他们看到消息到达，则说明他们输入了有效的凭据。
因为许多 Discourse 实例使用不同版本的 Discourse，如果在另一个网站上观察到可以进行密码重置的功能，我可能会假设 OpenAI 的实例运行的是较旧的版本，没有将“用户名”一词附加到字符串中。因此，这将为我节省这次折腾。
啊，对，这确实是个合理的场景……不过我想电子邮件别名服务应该会记录哪些别名在哪些地方使用过？苹果的服务就是这样，但我没有使用其他服务的经验，所以不确定。
也许值得提交一个功能请求，要求始终允许使用用户名进行密码重置？如果其他人也遇到这个问题，我们可以考虑实现这一功能。
没错。如果你想使用某项服务并继续使用它，记住你使用的电子邮件地址是你的责任。如果你忘了，那就得创建一个新账户。其他替代方案都要糟糕得多。给管理员发邮件（他们不公开自己的电子邮件地址，所以你需要创建一个新账户来联系他们），然后说：“呃，我用一个我不知道的电子邮件地址创建了账户。我不知道它是什么，所以无法证明我拥有它。”或者你可以问：“我创建了一个用户名 secret123，我忘了用了什么电子邮件地址，你能告诉我吗？”
如果你 paranoid（多疑）到使用随机电子邮件地址，那你应该也 paranoid 到使用密码管理器来帮你记住这些信息，否则，你就真的没辙了。
@pfaffman，我并没有忘记。事实上，是 OpenAI 随意断开了他们的 SSO（单点登录）集成，并在未通知的情况下将其替换为用户 OpenAI 账户中继承的电子邮件地址，且默认未绑定密码。正如 @awesomerobot 所推测的那样：
……确实，它（Addy）会记录，不过在这种情况下，我只是使用了我的凭据管理器中仍绑定到我 OpenAI 账户的那个别名。
@pfaffman，除非我误解了你本意可能只是幽默的话，否则我不欣赏你假设这是出于无能，更不欣赏你仅仅因为我使用了电子邮件中间件就指责我“多疑”。
为了详细说明后者，我使用别名服务来进行邮件分类，因为我担任圣约翰救护队的紧急响应员、英国海岸警卫队的救援官员，并且是多家国家和地方慈善机构（包括犯罪举报信托基金和社区守望网络）的受托人和委员会成员。在这些工作中，我经常与我所在郡的[警方及犯罪]专员办公室进行联络。此外，所有这些信息都进入同一个邮箱，该邮箱还接收我所有的 FOSS（自由及开源软件）工作邮件、个人通信（如信息权申请）以及安全警报。因此，为了优先处理而将其分开对我来说至关重要。
在我使用别名服务之前，我的旧邮箱被来自私人及国家行为体的鱼叉式网络钓鱼攻击所淹没。自从我使用这项服务以来，能够控制和分析谁将哪个电子邮件地址分享给了谁，使我能够将此类垃圾邮件的数量减少到以前的不到 2%。
请考虑一下，傲慢无礼甚至不如讽刺幽默。
@awesomerobot，谢谢。我已经提交了一个请求：
听起来确实是一团糟。
听起来你肩负着重要的工作，涉及他人的隐私与安全，这让你比大多数人更有理由保持警惕。我认为我们每个人都有理由保持警惕。据一位老者的看法，我们大多数人的警惕程度远不及应有的水平。
我的观点是，如果你失去了对电子邮件地址的控制，你就应该预料到重新连接到与该地址关联的服务将会变得困难甚至不可能。否则的话，无论你是否仍控制着该账户，别人都可能接管它。
换句话说，比无法访问你丢失的账户更糟糕的情况，是别人能够访问它，尤其是当你从事着保护他人隐私的重要工作时。
但也许存在某种安全的方法，能让你找回账户，同时确保地球上没有任何其他人能如法炮制。这是一个非常棘手的问题。或许你是在建议某种我不理解的安全解决方案。
我无意冒犯。
这句话读起来像是管理员更改了该设置的默认值。然而，该设置默认是启用的：https://meta.discourse.org/t/hiding-e-mail-taken-on-sign-up-by-default/342599。因此，除非管理员明确禁用它，否则它将保持启用状态。
这是一个非常棒的观点，这也（显然）意味着在密码恢复工具中，用户名输入默认是禁用的。因此，我现在更加喜欢这个功能请求，但我只被允许投一次票。
@pfaffman，使用 IETF RFC 5233 子地址（OnMicrosoft/Outlook 和 GMail / Google Workspace 均支持此功能）也会引发该问题，前提是您的地址未被记录。
不过，我的凭据管理器中确实有记录，而且我的别名工具也允许我搜索它们：
等等。我错过了重置密码界面不再接受仅输入用户名这一事实。只有在人们通过重置密码骚扰用户的情况下，这才有意义，而且我以为已经有速率限制措施来阻止这种情况。我想知道这个更改实际解决了什么问题。
而且，根据我的经验，在长期存在的社区中，用户不再记得自己的电子邮件地址并不罕见。
所以……我关于你应该知道自己注册时使用的地址的长篇大论是完全错误的。我是个混蛋，我谦卑地收回我的话。
现在，我想我理解了你的问题，而且这个问题似乎是由你所在社区的拥有者故意造成的。虽然这可能部分归咎于新的默认设置，但我认为这些人可以更改 hide_email_address_taken 的值……
等等。为什么 hide_email_address_taken 要求用户输入电子邮件地址而不是用户名？使用用户名重置密码不会暴露电子邮件地址。这才是真正的问题。
这个问题有几个层面是我没有理解的。很抱歉我如此没有帮助。
我刚投了我的票。这还能改进 
@pfaffman，其实我很高兴这迫使我进一步阐述。你的困惑与我的如出一辙；我们的思维过程完全相同！
虽然我明白有些用户可能会收到大量的密码重置请求，但如果他们确实被如此大量的请求淹没，以至于速率限制不够用，那么他们在自己的端点上依据 IETF RFC 5228 将这些请求过滤到单独的文件夹中，并非不可行。