多种方式登陆模块设计

多种方式登陆模块设计

---

目录

---

参考了一些资料

• 知乎 第三方一键登录如何保证产品的唯一ID？
• 开源中国社区 使用第三方登录,怎么设计自己的用户表
• segmentfault 带第三方登录的用户表如何设计
• 德问 当一个系统可以同时使用用户名/邮箱/手机号注册时，数据库应如何设计
• mob文档（是一个专门做第三方登陆的网站）

---

总结一下

可以分为两种登录方式：

• 第一种：使用 用户名/邮箱/手机号 + 密码 登陆。
• 第二种：第三方登陆 。

---

1# 使用 用户名/邮箱/手机号 + 密码 登陆。

设计数据表users的列为(uid, username, email, phone, passwd) 其中username、email、 phone都应该是unique。

登录时 select 1 from users where username = '' or email = '' or phone = '' and passwd = '';

• 这样做的缺点是，A的用户名可以设置成是B的电话号码或者邮箱。
• 可以使用正则表达式来区分出邮箱和电话号码。如果是这两种格式则不允许注册为用户名？
• 也可以用正则表达式来区分出是邮箱还是电话号码，然后再查数据库。

---

2# 第三方登陆。

请求第三方登陆通常会返回一个openid。

设计数据表third为(uid, openid, accessToken, type) ,分别对应users表的uid， 第三方登陆的openid，第三方登陆的accessToken， 第三方登陆的类型（如微博=1、qq=2）。

登陆的流程可以参照前文segmentfault的流程图。

大概就是：

• 如果在数据表中没查到这个第三方登陆的openid，那就往数据表里填入，代表新用户注册，然后可以引导用户填写 用户名/邮箱/手机号 + 密码 将两种登陆关联起来。当然也可以跳过引导步骤。那么可以uid填一个随机字符串之类的。
• 如果在数据库中查到了第三方登陆的openid，代表用户已注册，那就直接登录成功。

mob文档中还有以下描述

选择好平台以后，现在思考下面的问题：

你的应用是否具备独立账户系统？
这个问题是第三方登录时接口选择的重要标准。如果你选择“是”，则意味着你的应用只是需要第三方平台的用户，而不是他们的账户验证功能——也就是“要数据，不要功能”。而如果你选择“否”，则表示你实际上是’“要功能，不要数据（用户）”’。对于ShareSDK来说，前者你的入口方法是showUser(null)，而后者是authorize()。那么下面我分情况解释两种接入方式的步骤。

要数据，不要功能

如果你的应用拥有用户系统，就是说你的应用自己就有注册和登录功能，使用第三方登录只是为了拥有更多用户，那么你可以依照下面的步骤来做：

1、用户触发第三方登录事件
2、showUser(null)请求授权用户的资料（这个过程中可能涉及授权操作）
3、如果onComplete()方法被回调，将其参数Hashmap代入你应用的Login流程
4、否则提示错误，调用removeAccount()方法，删除可能的授权缓存数据
5、Login时客户端发送用户资料中的用户ID给服务端
6、服务端判定用户是已注册用户，则引导用户进入系统，否则返回特定错误码
7、客户端收到“未注册用户”错误码以后，代入用户资料到你应用的Register流程
8、Register时在用户资料中挑选你应用的注册所需字段，并提交服务端注册
9、服务端完成用户注册，成功则反馈客户端引导用户进入系统
10、否则提示错误，调用removeAccount()方法，删除可能的授权缓存数据
要功能，不要数据

如果你的应用不具备用户系统，而且也不打算维护这个系统，那么你可以依照下面的步骤来做：

1、用户触发第三方登录事件
2、调用platform.getDb().getUserId()请求用户在此平台上的ID
3、如果用户ID存在，则认为用户是合法用户，允许进入系统；否则调用authorize()
4、authorize()方法将引导用户在授权页面输入帐号密码，然后目标平台将验证此用户
5、如果onComplete()方法被回调，表示授权成功，引导用户进入系统
6、否则提示错误，调用removeAccount()方法，删除可能的授权缓存数据

---

思考

上述想法都只是查资料和一些构思，并没有实际做出来项目，以后有机会应该真正实现这个登陆系统。