2014-05-17 66 views
0

我正在使用Facebook,Twitter,电子邮件实施多重登录系统。多重登录功能

如果用户使用Facebook登录,他可以将他的账户与Twitter账户或电子邮件账户合并,因此下次登录时,他可以按“使用Twitter登录”或键入电子邮件+密码登录。

现在的问题是合并。

如果用户使用Facebook登录创建帐户A,修改一些数据,然后使用Twitter登录创建帐户B并修改一些数据,这将很难合并,因为这两个帐户将具有不同的数据。

使用多次登录的应用程序/网站如何处理这种情况?还是让我变得复杂?

回答

0

我想要说明的重点不是使用登录方法存储任何详细的帐户信息。这可能是您的用户帐户数据库是什么样子现在:

- account_id: … 
    facebook_auth_info: … 
    username: … 
    birth_date: … 
- account_id: … 
    twitter_auth_info: … 
    username: … 
    birth_date: … 

现在,这个架构应该让一个无操作为“合并帐户”:

- account_id: … 
    facebook_auth_info: … 
    twitter_auth_info: … 
    username: … 
    birth_date: … 

换句话说,对待Facebook,微博和其他作为“身份提供者”,并允许为您自己的帐户提供多个身份提供商。

0

我会这样做的方式是保持分开的第三方登录详细信息,并使用电子邮件和第三方登录详细信息表可互换以验证用户。通过这种方式,您可以让一位客户通过使用电子邮件或使用第三方登录进行授权。这并不意味着同一用户可以通过电子邮件&密码或第三方提供商登录。我发现避免在User表中存在第三方提供者的所有时间字段会很有帮助,并且如果您想添加更多登录提供者,则不必更改任何表,只需在Types表中添加另一个条目即可。

例如,我会使用用户表格,您可以在其中保留客户的所有详细信息,但登录详细信息。没有电子邮件,密码或任何其他登录信息。这些细节保存在单独的表格中,并由此表中的PK链接。 此表将映射1:1到电子邮件表。例如,一个模式可能是:

- Id (PK) 
- FirstName 
- SecondName 
- etc. 

然后,我将有一个电子邮件表在那里我会保留电子邮件和密码的用户。您还可以拥有“身份证”和“已验证”等其他详细信息(了解电子邮件是否已通过验证)请注意保持纯文本密码或保持对电子邮件密码在您的分贝。这是一个重要的安全问题,我不会在这里讨论。我还会使用UserId列将电子邮件映射到用户。 这将映射1:1到用户表。一个模式可能是:

- Id (PK) 
- Email 
- Password 
- UserId (FK) 
- Verified 

要处理的第三方登录信息,我会使用一个表名为ThirdPartyUsers。在这个表中,我将存储一个UserId,将来自该表的一条记录映射到用户表中的一条记录。基本上这个表可以替代电子邮件表,你可以从你的数据库中保存电子邮件密码。在这个表中,我会保留一个来自类型表的代码的ProviderCode和一个由第三方登录提供的Id的ProviderId。这些ID是每个第三方提供商独一无二的,并且不会更改每个用户。您可以将ProviderCode与ProviderId配对以生成组合密钥。 这将映射1:1到用户表。一个模式可能是:

- Id (PK) 
- UserId (FK) 
- ProviderCode 
- ProviderId 

有一个统一的用户帐户,我想有一个MasterUsers表中,可以定义一个用户作为主用户,你定义成一个链接表的儿童。通过其子女,我了解任何具有相同电子邮件地址的帐户。这意味着一个经典的帐户和任何第三方登录提供商。使用这个你可以有一个独特的主人和多个孩子。 这将映射1:1到用户表和1:*到MasterLinkToChildren表。一个模式可能是:

- Id (PK) 
- UserId 

向多个客户链接到一个MasterUser我会使用称为MasterLinkToChildren链接表(或任何命名你喜欢)。在这里,我将有两列用于存储儿童的UserIds和父母的MasterId。我要做的一件重要事情是让任何MasterUser在链接表中成为他自己的孩子,因此当您更新MasterUser时,您将保持记录之间的一致性。 这将映射*:1到MasterUsers和1:1到用户表。一个模式可能是:

- MasterId (FK) 
- UserId (FK) 

最后,我想有一个代码表,其中我将存储唯一的代码为每个第三方登录提供。 这将映射1:*到ThirdPartyUsers。就像一个模式:

- Id (PK) 
- Code (Unique) 

它看起来像一个大量的代码和许多表,但这样你可以保留独特的用户登录,也可以统一在一个主账户的一切。我不会自动合并它们,但我会为用户提供选择。您需要考虑的另一件事是不允许用户在验证帐户之前登录或合并帐户。我没有在ThirdPartyUsers表上使用Verified列,因为我不想验证这种类型的用户,但您也可以这样做。

通过使用代码表,您可以扩展您的第三方登录提供程序而不更改其他表。