共计 2463 个字符,预计需要花费 7 分钟才能阅读完成。
多账户的对立登录
名称解释
这里的多账户区别于零碎级别的,咱们讲的多账户零碎是指,在咱们互联网利用当中,咱们的利用会应用多个第三方账号进行登录,比方当初罕用的 APP:网易、微信、QQ 等等。
本文内容
多账户零碎的技术计划细节,以及相应的表设计,流程设计。
架构演进
初期
归结为初期是因为这个时候用户量比拟少,甚至还没有接入下面所说的其余第三方的账户零碎,只是自建的体系就能够满足,自建体系目前罕用的有:
用户名明码注册登陆
这种形式在很多初期网站建设会应用,先注册,再进行登录,在老一点的 cms 中都能找到这个影子。
- 流程图:
- 流程阐明:
1、前端将用户名、密码发送到服务器,服务器进行惯例的判断,判断用户名、明码长度是否满足,用户名是否反复等条件,条件不通过间接返回对应错误码给到前端,这里明码字段,为了避免传输过程中被截胡,倡议加密再上传,咱们的传输明码默认都是会进行一个 md5 加密,而后记录到数据库再进行一层加密,就算是脱库也没事,明码不要明文存储。
2、校验通过后,就将用户名明码写入数据库,并进行前面积分发放等操作,这里不开展。
3、当初进行登录,前端将用户名,密码发送给到服务端,服务端首先会校验登录次数是否超过设置的阈值,如果超过只能持续期待被关小黑屋。
4、如果未超过持续登录逻辑,判断用户名、明码是否正确,不正确明码则进行阈值的判断,如果超过则关小黑屋,记住小黑屋必须设置过期工夫,要不然就会永恒关上了,这个能够用 redis 的过期来做。
5、登录胜利后进行后续的所有后置逻辑,比方加积分 … 等操作。
手机号注册登陆
- 流程图
- 流程阐明:
1、首先输出手机号,而后发送到服务端,服务端将手机号记录在咱们数据库中,而后生成随机验证码,并将手机号和验证码绑定到一个 redis 外面,而后记录过期工夫,这个过期工夫个别是 10 分钟左右,这就是咱们个别手机验证码的有效期。
2、手机接管到手机短信后,那么就在界面填写验证码发送服务端,服务端收到验证码后就会在 redis 外面查问到这个手机号对应的验证码,失败就返回错误码。
胜利后就进行登录操作。
3、这里看起来没有明确的注册登录操作,其实在发送手机号码就能够认为是一个惯例的注册,而后前面的验证码输出就是一个登陆操作。
问:如果要明码怎么办?
答:在后续产品外面减少一个“手机号码明码补录的性能”即可,这也是当初很惯例的手法,然而当初挪动互联网大爆炸时代,明码曾经显得不是那么重要了,如果手机号码能操作的 app,能够不必明码来操作。
数据库设计
表构造:
自增 id | 用户名 | 明码 | 手机号 | 谬误次数 |
1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
阐明:
这里只是单纯阐明须要用到的数据,没有扩大具体场景, 这个表构造可能满足下面两个计划的设计。
引入第三方账户计划
这里是以 QQ-SDK 的登录逻辑,咱们先看一下时序图:
- 阐明:
1、客户端本人调起登录的界面,进行输出用户名、明码,这里的是第三方的用户名,明码,登录胜利后,会返回 access_token openid expire_in, 这过程会应用到 oauth2.0,不过在 sdk 外面进行内置回调获取了,前面咱们会阐明咱们本身实现的 oauth2.0
2、客户端拿到 access_token、openid、login_type(qq、wechat…)申请应用服务器,应用服务器拿到这些数据后就会依据对应的 login_type 去对应的用户核心进行 access_token 和 openid 进行校验。校验不通过则返回对应错误码
3、校验通过后就会判断本地是否有这个 login_type 和 openid 是否存在,不存在则进行获取近程的用户名、头像等根底信息来作为本地根底数据,并且返回 code 值
4、如果曾经存在,那就是进行登录操作,返回 code 值。
5、客户端拿到 code 值后进行 token 值的换取,这个齐全遵循 oauth2.0 的协定来走的,后续每次申请必须带上 token,token 值在服务端的工夫比拟久,因为咱们想要做的是那种永不下线的操作,所以每次申请咱们都将 token 过期工夫进行累加。
数据库设计
用户根底表(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, 校验应用 |
- 阐明
1、users 表只是单纯针对咱们业务侧的登录,次要是做本身业务的 oauth2.0 业务,
2、user_local_auth 是做本人用户名、明码登录,手机号码登录信息记录,
3、user_third_auth 是咱们第三方用户体系的数据记录,
4、user_auth_rel 是用来关联咱们 users 表与 user_local_auth、user_third_auth。
5、整个设计理念就是将自建用户与第三方在存储上辨别,这在架构演进上也是合乎情理的,开始用户体系大多自建,而后才是对外接入。
总结
1、总的来讲,第三方用户的接入技术上来讲是比较简单的,这里设计多一个 user_thirds 是能够反对足够多的第三方接入,当然个别咱们也就两三个登录就好,太多登录方不仅减少本身保护老本,界面摆盘也不难看。
2、这里的设计方案不蕴含分表分库、没有服务化,就是简略间接的设计。
正文完