OmniAuth：防范同一用户的多个帐户答案

【问题标题】：OmniAuth: Guarding against multiple accounts for the same userOmniAuth：防范同一用户的多个帐户
【发布时间】：2011-01-10 06:58:50
【问题描述】：

我有几个 Rails 应用程序希望与 OmniAuth 集成，但我想先解决一个概念问题。考虑以下场景：

您的应用程序 Foo 支持通过 Twitter 和 Facebook 进行 OmniAuth 登录。
Joe 访问您的站点并通过他的 Twitter 帐户登录。这会在 Foo 上创建一个新用户并将其与这个新的 Twitter 授权相关联。
Joe 退出了 Foo，并在六个月内忘记了该网站。
Joe 回到 Foo，不记得他以前使用 Twitter 登录过。
Joe 使用 Facebook 登录。由于他尚未通过原始 Twitter 授权登录，因此无法检测到他实际上是同一个 Joe，因此会创建一个新帐户。
Joe 发现了他的旧帐户，现在他很沮丧，因为他的旧内容与这个旧帐户绑定在一起，而且他无法交替使用 Twitter 和 Facebook 登录。

由于 Twitter 不向 Foo 提供电子邮件地址，因此没有通用标识符可用于检测这两个 Joe 是同一个 Joe。您可以决定仅支持向您提供用户电子邮件地址的提供商，但如果用户在不同提供商的不同电子邮件地址上注册，这将无济于事。

我能想到的唯一其他解决方案是为用户提供一些合并两个现有帐户的方法。与使用 OmniAuth 时其他一切相对容易相比，这是一个令人头疼的问题。如果这是唯一的解决方案，是否有人遇到过指南/教程，显示了如何完成此操作的示例？鉴于 OmniAuth 的流行，我很惊讶这个问题没有得到更多关注。

谢谢！

【问题讨论】：

我看不到这个问题的完美解决方案。所以，我决定暂时选择单一供应商，直到找到可靠的解决方案。
嗨 Jimmy Cuadra，您可以访问 try.discourse.org。 Discourse 使用omniauth 实现了多个注册选项。它的源代码在 GitHub 上可用。

标签： ruby-on-rails omniauth

【解决方案1】：

你的直觉是正确的。您必须为您的用户提供一个合并工具......或者您可以忽略这个问题。

【讨论】：

这是公认的答案吗？有人发现了一个不错的合并工具吗？
因为这是唯一可能的答案？您无法阻止用户意外获得两个帐户。没有一种合并工具可以知道在您的应用程序中要做什么。用于帮助简化合并过程的唯一最佳实践是将身份验证身份与应用中的实际用户配置文件分开。这样，您的应用就可以允许多个身份验证提供商链接到单个用户配置文件。

【解决方案2】：

我知道这是一个老问题，但我想我会用我最近在一个项目上所做的来回答，仅供参考。

完全披露：这不是我想出来的，我是从网络上的其他人那里偷来的。 on the Omniauth wiki 写得很好。

我从来没有找到一种自动链接 Facebook/Twitter/etc 帐户的好方法，而是让用户在使用第一个帐户登录后可以链接多个帐户。

这是场景：

用户使用例如登录脸书
他们有一个个人资料页面，其中列出了他们附加到帐户的社交网络，以及将每种类型链接到帐户的选项
- 例如“Facebook 链接 | 链接 Twitter | 链接 Google”
“链接 Twitter”，例如指向用户用于登录 Twitter 的同一个omniauth 操作的链接
在回调处理程序中，检查用户是否登录
- 如果是，请将提供程序和 uid 存储在单独的记录中以供用户使用
- 否则，照常登录

不是将提供者和 uid 存储在用户模型上，而是该模型将是一个用户，可以拥有许多社交网络身份。

再次，抱歉让死者复活，但 Abe Petrillo 对已接受答案的回复让我认为另一种观点可能有用。

【讨论】：

这很有帮助。我正试图做到这一点。非常感谢:)

【解决方案3】：

我今天也遇到了这个问题。我想我会这样处理：

我会在注册时询问用户他们的电子邮件和密码，就像在传统的身份验证设置中一样，我尝试从用户选择的 OmniAuth 服务（FB、Twitter 等）获取电子邮件.因此，如果身份验证提供商未提供电子邮件，他们只需提供电子邮件。然后，如果用户稍后使用他们用于注册的同一提供商登录，他们将立即登录。这可能会在 99% 的情况下发生。

但是，有了用户的电子邮件和密码，我也可以处理可能发生的各种情况（包括您描述的情况）：

原来的身份验证提供商已关闭或用户删除了他们的身份验证提供商帐户 -> 解决方案：用户可以使用他们的电子邮件和密码以传统方式登录。（请注意，这是一个重要的案例，我还没有在网上看到任何地方提到过。人们似乎认为 FB、Twitter 等将永远存在，永远不会关闭，用户永远不会退出他们的帐户服务。通过不存储用户密码和电子邮件，如果发生这些情况之一，您将丢失由提供商生成的所有用户帐户，因为您无法再将它们映射到用户。对我来说，这是不可接受的依赖外部服务。）
用户稍后使用不同的身份验证提供商登录（这是您的情况）-> 解决方案：尝试使用他们的电子邮件将用户映射到现有帐户，如果失败，则显示带有按钮的注册表单/link “我已经有一个帐户，请登录”（或类似的 ;-)。如果他们点击它，他们必须提供他们的电子邮件和密码。然后，如果他们成功通过身份验证，您只需将该提供商添加到现有用户记录中，下次他们立即登录，就像他们最初用于注册的提供商一样...

也许还有其他可能发生的情况。有什么反馈吗？

【讨论】：

我认为更好的方法实际上是完全依赖电子邮件并通过电子邮件将额外的外部身份验证映射到内部用户。然后向用户发送一封带有链接的邮件，以验证他们的身份。这比使用“备份密码”更方便。

【解决方案4】：

我注意到 Stack Overflow 似乎在某种程度上试图克服这个问题，方法是将用户的身份验证首选项存储在 cookie 中，并在您返回登录页面时自动登录。

虽然它仍然没有为这个问题提供完整的解决方案，但它可能有助于最大限度地减少后果。

【讨论】：

或者如果用户更换电脑
或其他用户使用相同的计算机和浏览器
...我认为最迫切需要解决的是最后一个反对意见，当多个用户共享同一台计算机时，那将是一团糟！