这里的多账户区别于系统级别的,我们讲的多账户系统是指,在我们互联网应用当中,我们的应用会使用多个第三方账号进行登录,比如现在常用的APP:网易、微信、QQ等等。
通过这一篇文章:
归结为创业初期是因为这个时候用户量比较少,甚至还没有接入上面所说的其他第三方的账户系统,只是自建的体系就可以满足,自建体系的话,目前常用的有
这种方式在很多初期网站建设会使用,先注册,再进行登录,在老一点的cms中都能找到这个影子。
流程图:
流程说明:
流程图:
流程说明:
这里看起来没有明确的注册登录操作,其实在发送手机号码就可以认为是一个常规的注册,然后后面的验证码输入就是一个登陆操作,
问: 那我要密码咋办?
答: 在后续产品里面增加一个 手机号码密码补录的功能 即可,这也是现在很常规的手法,但是现在移动互联网大爆炸时代,密码已经显得不是那么重要了,反正我从来记不住密码,如果手机号码能操作的app,绝对不用密码来操作。
表结构 :
自增id | 用户名 | 密码 | 手机号 | 错误次数 |
---|---|---|---|---|
1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
说明 :
这里只是单纯说明需要用到的数据,没有扩展具体场景,这个表结构能够满足上面两个方案的设计。
这里是以QQ-SDK的登录逻辑, 我们先来一波时序图
说明:
根据部分小伙伴的的建议,我这里做一下数据库的整理:
用户基础表(users)
字段 | 备注 |
---|---|
user_id | 用户id |
token | 用户登陆的token |
expire_in | token过期时间 |
try_times | 登录失败次数 |
用户验证关联表(user_auth_rel)
字段 | 备注 |
---|---|
id | 自增id |
user_id | 用户id |
auth_id | 验证表id |
auth_type | 验证类型(local、third) |
本地用户表(user_local_auth)
字段 | 备注 |
---|---|
auth_id | 认证id,自增id |
user_name | 用户唯一标识 |
password | 用户密码 |
mobile | 用户手机 |
第三方用户表(user_third_auth)
字段 | 备注 |
---|---|
auth_id | 用户id |
openid | 第三方用户唯一标识 |
login_type | 第三方平台标识(qq、wechat...) |
access_token | 第三方获取的access_token,校验使用 |
说明
END