多种方式登陆模块设计

多种方式登陆模块设计


目录


参考了一些资料


总结一下

可以分为两种登录方式:

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

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()方法,删除可能的授权缓存数据


思考

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

阅读更多
换一批

没有更多推荐了,返回首页