友户通----https://apcenter.yonyoucloud.com/

⽤户登录系统数据库表设计 ⽤户登录系统数据库表设计 最近看了看公司后台⽤户登录系统的设计， ⽐较混乱， 主要还是因为URS和Oauth以及URS第三⽅这三个登录形式各不相同导致的。 下⾯着重介绍⼀下涉及到第三⽅登录中需要注意的问题 在⼀个新项⽬中， 如果是要建⽴⾃⼰的登录体系的话， 那么直接创建⼀个Users表，包含username和password两列，这样，就可以实现登录了： 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 ----+------------+----------