用户登录系统数据库表设计

最近看了看公司后台用户登录系统的设计, 比较混乱, 主要还是因为URS和Oauth以及URS第三方这三个登录形式各不相同导致的。

下面着重介绍一下涉及到第三方登录中需要注意的问题

 

 

在一个新项目中, 如果是要建立自己的登录体系的话, 那么直接创建一个Users表,包含usernamepassword两列,这样,就可以实现登录了:

 id | username | password | name等其他字段
----+----------+----------+----------------
 A1 | bob      | a1b23f2c | ...
 A2 | adam     | c0932f32 | ...

如果要让用户通过第三方登录,比如微博登录或QQ登录,怎么集成进来呢?

以微博登录为例,由于微博使用OAuth2协议登录,所以,一个登录用户会包含他的微博身份的ID,一个Access Token用于代表该用户访问微博的API和一个过期时间。

要集成微博登录,很多童鞋立刻想到把Users表扩展几列,记录下微博的信息:

 id | username | password | weibo_id | weibo_access_token | weibo_expires | name等其他字段
----+----------+----------+----------+--------------------+---------------+----------------
 A1 | bob      | a1b23f2c | W-012345 | xxxxxxxxxx         | 604800        | ...
 A2 | adam     | c0932f32 | W-234567 | xxxxxxxxxx         | 604800        | ...

加一个QQ登录Users表就又需要加3列,非常不灵活

 

那么我们需要对这个表进行拆分。当用户以任意一种方式登录成功后,我们读取到的总是Users表对应的一行记录,它实际上是用户的个人资料(Profile),而登录过程只是为了认证用户(Authenticate),无论是本地用密码验证,还是委托第三方登录,这个过程本质上都是认证。

所以,如果把Profile和Authenticate分开,就十分容易理解了。Users表本身只存储用户的Profile, 其中ID为关联不同登录方式的外键。

 id | name | birth等其他字段
----+------+-----------------
 A1 | Bob  |  ...
 A2 | Adam | ...

而通过用户名口令登录可视为一种Authenticate的方式,利用LocalAuth表维护:

 id | user_id | username | password
----+---------+----------+-----------
 01 | A1      | bob      | a1b23f2c
 02 | A2      | adam     | c0932f32

通过微博登录可视为另一种Authenticate方式,利用OAuth表维护, 但是access_token一般情况也只有几个小时的时效, 所以存储它是没有意义的, 每次登录的时候去微博后台验证一下客户端传来的token就行了。 如果用户只用了第三方登录, 那就拿第三方数据来填充刚才的User表即可。

 id | user_id | weibo_id |
----+---------+----------+
 11 | A1      | W-012345 |
 12 | A2      | W-234567 |

如果要添加另一种OAuth登录,比如QQ登录,那就再加一个列标示不同站点也就OK了, 但是要注意用户在不同登录方式的用户名和photo一般不一样, 所以也单独存起来

 id | user_id | oauth_name | oauth_id | nick_name| photo|
----+---------+------------+----------+----------+------+
 11 | A1      | weibo      | W-012345 | 
 12 | A2      | weibo      | W-234567 |
 13 | A1      | qq         | Q-090807 |
 14 | A2      | qq         | Q-807060 |

通过这种方式, 无论用户采用哪种方式登录, 都可以锁定到用户的user_id。

下面再说一下网易的URS登录, 因为我们要直接采用网易通行证, 所以也就不需自己存储密码, 因此我们的架构应该设为User表

 id | user_Email | username | birth
----+------------+----------+-----------
 01 | aa@126.com | bob      | 
 02 | bb@126.com | adam     | 

如果用户只用第三方登录, 显然无法填充user_Email这个字段, 因此userEmail可以为空。 如果第三方登录采用的是URS第三方的接口, 它返回的oauth_id 是aa@wx.163.com这种形式。 具体设计和上面也类似。 整体上使用这种方式比现在后台的逻辑要清晰很多

posted on 2016-05-23 22:48  777车队  阅读(6463)  评论(0编辑  收藏