问题 1 和 2 是由苹果有意的实现选择导致的。因此，这并非真正的技术故障，我们可以找到变通方案。问题 3 出在 omniauth-apple gem 上，因此我们可以修复它。
我们需要苹果方面在后续的认证流程中包含姓名和电子邮件。不幸的是，他们已确认该行为，并表示这是按设计运行的：Cannot get email & name while scop… | Apple Developer Forums
此行为符合预期，用户信息仅在初始用户注册时通过 ASAuthorizationAppleIDCredential 发送。使用同一账户通过“使用 Apple 登录”再次登录您的应用时，不会共享任何用户信息，ASAuthorizationAppleIDCredential 中仅会返回用户标识符。建议您安全地缓存包含用户信息的初始 ASAuthorizationAppleIDCredential，直到您能在服务器上验证账户已成功创建。
不过我很好奇，是否有人见过其他网站使用“使用 Apple 登录”？我觉得我只见过原生应用在使用它：thinking:
这个功能对我来说非常有意义：我们的 iOS 应用链接到我们的 Discourse 网站，而应用本身对其他功能没有登录要求。
用户使用这种方式登录非常便捷，因为大多数用户已经在设备上登录，且用于应用内购买的 Apple Pay 也使用同一个账户。
依我之见，联系苹果 DTS 咨询他们建议的变通方案，并向他们反馈此问题正在造成困扰，仍然很有意义。（遗憾的是，我本人对此了解不足，无法与他们就此展开讨论。）
虽然远不如 Google、Facebook 等普及，但我确实在一些地方见过，例如 ebay.com、wordpress.com 和 kayak.com。
不过它们可能使用的是不同的 API。虽然有一个可以添加的 JS 脚本，但我怀疑它无法与 Discourse 更通用的 OAuth 系统集成：
我们以 Kayak.com 为例。
如果我在浏览器检查器中稍作调查，会发现以下内容：
是的，他们正在使用 Apple 的 JavaScript 库。但在后台，它仍然使用相同的“OAuth”（实际上并非真正的 OAuth）API。
Ebay 甚至没有尝试获取用户信息。使用 Apple 登录后，系统会要求你提供电子邮件：
我怀疑 Kayak 和 WordPress 是根据 Apple 的建议，缓存了首次认证尝试中的用户信息。
我想这可能是我们需要采用的方法，但它并不特别稳健（例如，如果在首次尝试期间网络连接中断，或者 Discourse 从备份中恢复，或者用户更改了他们的 Apple 电子邮件地址）。而且，在我看来，从隐私角度来看，这略微更差（我们必须存储那些甚至尚未注册用户的电子邮件！）
我认为苹果最新的 iOS 更新现在让这变得可行，不是吗？
最近与“使用 Apple 登录”相关的功能有变化吗？
我们当然可以按原样使其正常工作——这需要几天时间来绕过这些问题。但之后，我们仍然只能在首次登录时获取电子邮件和姓名。
我觉得他们稍微优化了一下，但我一时想不起具体的改动。
我认为只收到一封邮件应该不是什么大问题吧？我想我们需要测试一下，当你在 Apple ID 上更改邮箱时会发生什么。
我们应该继续收到相同的 UID，但不会收到新的邮箱地址。用户需要在 Discourse 中手动更新它。
我想我们应该再仔细检查一下，但说实话，我不认为这会成为阻碍我们实施该功能的大问题。
在 iDevice 上使用 Apple 登录的登录流程非常出色，而且还能通过 Face ID 实现双重验证。
我会将其加入清单，以便更新该插件并进行测试。如果运行正常，我们可以轻松将其移至核心部分。
已将仓库移交给 David，他已将其迁移至 Discourse 
感谢你接手这项工作。
我读了两三遍这个主题，但不记得你们是否尝试过从提供的 JWT token 中获取邮箱。
我在原生代码中是这样做的。我不确定 Web API 是否支持这种方式。
首次登录时，你可以直接从 ASAuthorizationAppleIDCredential.email 获取邮箱。
对于后续登录，如果解码 JWT 数据并获取 “email” 字段，就能找到邮箱。
有了这个，功能应该就能实现了吧？
提供的邮箱将是用户选择的，可能是个人邮箱，也可能是随机生成的。
是的，没错。
这与我的经验不符。我上次检查时，后续登录的 JWT 中并不包含邮箱地址。
无论如何，我们确实打算尽快实现此功能，并在准备好后更新此主题
这很奇怪，因为在原生端，我仅使用 JWT 的 email 属性就实现了功能。
如果他们在 Web 端不更新为类似的方案，唯一的解决办法可能就是在后台自动生成一个虚拟邮箱（自动确认），并允许用户之后根据需要自行修改。
这意味着需要依赖 Apple 提供的 ID，这不算太糟糕的方案，但确实有点让人不太放心 。
很有可能他们有所改进——我会再仔细检查一下：+1:
我们知道这可以实现。变得复杂的情况是：
jane.champion@somewhere.comjane.row@somewhere.comjane.champion@somewhere.com目前尚不清楚当 Apple ID 邮箱发生变更时，现有的处理流程是什么，以及我们是否以及如何对此作出响应。
我的建议是：我们就接受这一边缘情况，并至少允许用户在遇到此类情况时，在 Discourse 中自行更改邮箱地址。
我今天进行了测试，好消息是苹果似乎已经修复了这个问题 
我在每次认证中都能看到邮箱地址。
还有一些问题需要解决，但希望本周能发布公开版本。
我可以说，这绝对是一个可以随 Discourse 一起发布的候选功能。我们的目标应该是将代码整合到核心中，或者至少为下一个主要版本打包该插件（当然，不是下周发布的那个版本 :)）。
是的，我们稍后可以用极小的工作量将其从插件迁移到核心。一个问题是，与 Google、Facebook 等平台相比，它的配置极其困难。
你需要一个（付费的）Apple 开发者账号，并且要配置各种域名验证和证书。不过，只要有好的操作指南，这完全是可以实现的。