将多个用户帐户合并在一起的架构 [英] Architecture for merging multiple user accounts together

问题描述

好的，我有一个网站，您可以在其中注册和登录.您也可以使用您的 facebook、twitter 或linkedin 帐户登录.

Okay, I got a website where you can register yourself and login. You can also login with your facebook, twitter or linkedin account.

用户只注册一个帐户很重要.所以不知何故，如果用户使用不同的方法登录，我想合并用户的帐户.解决此问题的最佳解决方案是什么?

It is important that users only have one account registered. So somehow, I want to merge the accounts of users if they use different methods to login. What is the best solution to solve this?

例如，用户使用他的 Facebook 帐户登录.我使用数据自动为他注册一个帐户.我应该用我们网站的用户名和密码发送电子邮件吗?(如果这符合 Facebook 的政策).我应该给他们第二个屏幕让他们填写用户名和密码吗?但这不是使用您的 Facebook 帐户登录的想法.它应该可以简化您的参与程序.

For instance, the user logs in with his Facebook account. I use the data to register an account for him automatically. Should I sent an e-mail with an username and password of our website? (If this is okay with the policy of Facebook). Should I give them a second screen where they can fill in an username and password? But that's not the idea behind logging in with your Facebook account. It should simplify your procedure to participate.

也有可能用户已经在我们的网站上注册了自己，并在下次使用他的 Twitter 帐户登录时.如何将这两个帐户合并为一个?最好的方法是什么?

It's also possible the user has registered himself on our website and the next time he logs in with his twitter account. How can I merge these 2 accounts as one? What's the best way?

所以基本上我的问题是:我有 4 种不同的方式让用户成为我们网站的会员.如果用户决定使用多种方式，我如何确保所有这 4 种方式只创建一个帐户?确保它不会给用户自己带来麻烦的最佳流程是什么?

So basically my question is: I got 4 different ways a user becomes a member of our website. How can I make sure all these 4 ways only create one account if a user decides to use multiple ways? What's the best flow to make sure that it doesn't become a hassle for the user himself?

在我问这个问题 3 年后，我自己在一系列文章中给出了答案:https://www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social-network-authentication-google/
https://www.peternijssen.nl/social-network-authentication-merging-帐户/
https://www.peternijssen.nl/social-network-authentication-twitter-脸书/

3 years after I asked this question, I am giving the answer myself in a series of articles: https://www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social-network-authentication-google/
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/

推荐答案

我目前面临着完全相同的任务.我制定的设计相当简单，但效果很好.

I am faced with the exact same task at the moment. The design I worked out is rather simple, but it works well.

核心思想是本地站点身份和第三方站点身份的模型保持隔离，但稍后链接.因此，每个登录站点的用户都有一个本地身份，该身份映射到任意数量的第三方站点身份.

The core idea is that models for a local site identity and the third-party site identities are kept isolated, but are later linked. So every user that logs into the site has a local identity which maps to any number of third-party site identities.

本地身份记录包含最少的信息 - 它甚至可以是单个字段 - 只是一个主键.(对于我的应用程序，我不关心用户的电子邮件、姓名或出生日期 - 我只想知道他们是一直登录此帐户的人.)

A local identity record contains a minimum of information - it could even be a single field - just a primary key. (For my application, I don't care about the user's email, name, or birth date - I just want to know they're the person who has been logging into this account all along.)

第三方身份包含仅与第三方身份验证相关的信息.对于 OAuth，这通常意味着用户标识符(如 ID、电子邮件或用户名)和服务标识符(指示已通过身份验证的站点或服务).在应用程序的其他部分，在数据库之外，该服务标识符与从该服务中检索相关用户标识符的方法配对，这就是执行身份验证的方式.对于 OpenID，我们采用相同的方法，除了身份验证方法更通用(因为我们几乎总是可以执行完全相同的协议 - 除了我们使用不同的身份 URL，这是我们的服务标识符).

The third-party identities contain information relevant only to authenticating with a third-party. For OAuth, this typically means a user identifier (like an id, email, or username) and a service identifier (indicating what site or service was authenticated with). In other parts of the application, outside of the database, that service identifier is paired with a method for retrieving the relevant user identifier from that service, and that is how authentication is performed. For OpenID, we employ the same approach, except the method for authenticating is more generalized (because we can almost always perform the exact same protocol - except we use a different identity URL, and that is our service identifier).

最后，我会记录哪些第三方身份与哪些本地身份配对.要生成这些记录，流程如下所示:

Finally, I keep a records of which third-party identities are paired to what local identity. To generate these records, the flow looks like this:

• 用户首次使用第三方身份登录.创建本地身份记录，然后创建第三方身份记录，然后将它们配对.
• 在控制面板中，用户可以通过登录第三方服务来关联帐户.(它的工作原理非常简单.)
• 在用户不知不觉中创建多个帐户的情况下，解决方案非常简单.当用户登录其中一个帐户时，他会登录另一个他以前用于登录站点的帐户(通过上面的控制面板功能).Web 服务检测到此冲突(登录用户的本地身份与链接到刚刚登录的第三方身份的本地身份不同)，并提示用户进行帐户合并.

合并帐户就是合并本地身份的每个单独字段(这会因应用程序而异，如果本地身份记录中只有几个字段应该很容易)，然后确保链接的第三个字段- 当事人身份与由此产生的本地身份相关联.

Merging accounts is a matter of merging each individual field of the local identity (which will vary from application to application, and should be easy if you have only a couple fields in your local identity records), and then ensuring the linked third-party identities are linked to the resultant local identity.

这篇关于将多个用户帐户合并在一起的架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！