在互联网应用中,我们构建一个网站或APP,如果没有用户,那就没有价值。所以,如何吸引用户注册和登录,是一个重要问题,而这就涉及到账号体系了。
在应用构建初期,用户量较少,那么自建系统的账号体系就可以满足本身系统的业务需求。当应用用户量较多时(比如QQ、微信等用户量较多的应用),可提供第三方授权登录系统,为其他应用提供登录功能需求。常用登录如下:
其实很多最初构建的应用系统都是采用这种方式,用户先注册,再登录,才可操作相应业务。其流程图如下:
用户注册:
流程说明:
用户登录:
流程说明:
随着智能移动设备的普及,以及短信业务的成熟,现在很多应用都逐渐采用手机号注册登录这种方式来作为应用的登录需求。手机号注册登录这种方式省略常规的注册,通过验证码来进行注册登录,当用户进入应用后进行一个信息补录,完善用户信息即可。在如今信息时代,密码也就变得不那么重要了,手机号-验证码这种方式让用户能轻便的快速使用应用,不用去记太多的密码。其流程图如下:
流程说明:
数据库表设计(根据业务进行修改):
auto_id | userName | passWord | telephone | err_num |
---|---|---|---|---|
1 | user1 | 8js3d4w | 13847387443 | 2 |
2 | user2 | 2h1d68f | 19827372347 | 0 |
在开发微信小程序时,微信其实就是第三方,小程序的登录,实际上可以理解为以微信作为第三方进行授权登录,其流程和QQ、微博登录的流程几乎一致。时序图如下:
实现思路:
数据库表设计:
用户表(users Table):
字段 | 备注 |
---|---|
user_id | 用户id |
token | 用户登录的token |
expire_in | token过期时间 |
try_times | 登录失败次数 |
用户验证关联表(user_auth_rel Table):
字段 | 备注 |
---|---|
id | 自增id |
user_id | 用户id |
auth_id | 验证表id |
auth_type | 验证类型(local、third) |
本地用户表(user_local_auth Table):
字段 | 备注 |
---|---|
auth_id | 认证id(自增id) |
user_name | 用户key |
password | 密码 |
mobile | 用户手机号 |
第三方用户表(user_third_auth Table):
字段 | 备注 |
---|---|
auth_id | 用户id |
openid | 第三方用户唯一标识 |
login_type | 第三方平台标识(wechat、QQ等) |
access_token | 第三方获取的access_token(校验使用) |
补充说明: