一、统一帐号体系业务及模型

发表于： 2018年3月25日 2018年3月25日
分类： 18模, idea

本文节选自《你必须懂的18个互联网模型》已经发布在百度阅读平台,售价9.9元.购买地址

http://yuedu.baidu.com/ebook/977275a5767f5acfa0c7cd55

1 统一帐号体系业务及模型

1.1、场景描述

我们经常会碰到这样的需求，比如某企业需要做一个投诉报修的小系统，每个投诉报修的用户，如果他是第一次用微信登录我们的系统，那么需要输入手机号码，验证了这个手机号码后，才能进入我们的系统，提交报修信息。第一次报修后，以后用户再次提交报修信息，即可以自动识别该用户，免去登录的麻烦。我们的系统要能在微信里面运行，还要能在微博里面，浏览器里面运行,以后我们的系统还要做APP,用户同一帐号登录的APP和在微信微博里面登录的信息，应该是一样的。

类似于这类需求模型，我们都叫做统一帐号体系模型，他的大概整体流程是像下面这样的

该图重点在于统一登录流程，该流程的核心在于统一帐号体系，下面先来阐述统一帐号模型。

1.2、统一帐号核心模型

统一帐号模型的本质是以自有系统为基础，其他系统帐号标识ID与本系统相互绑定。一般的移动互联网体系中，核心帐号模型包含用户id,登录手机号、用户密码、头像、昵称、用户状态等，其他的信息，都可以在此基础上做扩展，如积分数目、用户等级、性别，年龄等,如果要使用邮箱、用户名等体系登录,我们还需要有独立的关联表，这些都在后面进行阐述。如下是统一账号基础模型。该模型中的id即为其他模型中的userid。

1.3、用微信等第三方平台登录

所谓用微信登录系统包括几个方面的内容，一是利用微信公众号在微信里面登录系统，二是利用APP调用微信授权接口登录APP，三是利用微信扫描登录PC站点，但是他们的模型是一样的，我们先以微信公众号为例说明。

1.3.1 在微信中利用微信公众号授权登录

微信公众号授权登录模型如下所示

1.3.2 利用微信开放平台支持登录

利用APP调用微信授权接口登录APP，以及利用微信扫描二维码登录PC站点都属于此类登录，此类登录的核心在于确定unionid和用户userid之间的关系。如下关于unionid的说明来自微信官方文档。

特别需要注意的是，如果开发者拥有多个移动应用、网站应用和公众帐号，可通过获取用户基本信息中的unionid来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号，用户的unionid是唯一的。换句话说，同一用户，对同一个微信开放平台下的不同应用，unionid是相同的。

如下是微信开放平台登录机制表，很简单的俩个字段

1.3.3、第三方平台登录流程

第三方平台登录的核心原理和微信帐号登录是一致的，首先通过auth2授权,获得用户标识和基础信息然后，系统利用该用户标识查询到与之广联的用户ID然后登录。流程如下。

备注说明:

本流程核心在于将openid存储到session中，当用户第一次登陆时，由于openid尚未绑定userid，当用户名和密码匹配时，首先检测当前session中是否存在openid，如果存在，则将该openid和用userid相互绑定。

1.4、设备登录、邮箱登录及其他登录

1.4.1 利用设备ID登录帐号

每一个设备都有一个id，这个ID与account_device 关系表绑定后，每次打开应用后立即获取设备ID和用户的关联关系，即可实现登录。在实际过程中，我们可能会使用第三方的PUSH token 作为设备ID，push token 第三方推送平台用来标识设备的，这些token是经过处理过的，一般来说，每一个平台的push token 是不一致的。我们也可使用IMEI作为设备ID。设备ID登录适用于APP登录。相关表结构如下。

1.4.2 邮箱和用户名登录

邮箱和用户名登录体系比较简单，关键在于建立核心的关联关系。相关表结构如下所示。

用户名绑定比较简单，后端需要鉴定一下是否被使用就可以了，如果已经被使用，则绑定失败，如果尚未使用，则提示可以绑定。邮箱绑定稍微复杂一些，如下展示了邮箱绑定的一般流程。

邮箱绑定的关键在于鉴定签名是否合法。下面以实际列子来展示绑定的一般流程。

假设我们有个站点，域名地址为 test.com，则第一步,用户登陆后在邮箱绑定界面输入他自己的邮箱x@y.com，然后点击提交，服务器后端此时收到信息，首先检测邮箱帐号格式是否正确,以及x@y.com 是否被占用，如果被占用了，那么提示该邮箱已经被绑定，如果尚未占用，则构造类似于如下的信息发送到x@y.com邮箱中，用户点击如下连接即可跳转到绑定页面。

你好,这是一封来自xx的邮件，我们收到了你的邮箱绑定请求，请点击如下地址完成操作。

http://www.test.com/account/bindEmail.php?email=x@y.com&userid={userid}&createat={createat}&noisy={noisy}&sign={sign}.

在如上连接中有几点需要说明:

为了保证信息的安全性，我们采用了签名策略，签名字段sign是基于邮箱帐号email、要绑定的用户编号userid、邮件发送时间戳createat、噪音noisy以及加密因子apikey的函数。其中加密因子apikey是本系统内置的加密信息函数，不暴漏到外部。

createat的作用在于鉴定邮件是否过期，假设我们规定如果发送时间距离当前时间俩天以前,则为无效，则我们就可以根据createat时间戳和当前时间戳对比来判断。超出俩天的为非法邮件，不予绑定。

一般地，对于签名算法我们可以采用sha1或者md5策略，只要系统内部约定好即可，示例代码如下：

static $apikey =”abc”;

/*签名构造函数*/

function makeSign($email,$userId){

$noisy = time() . mt_rand() *1000 ;

$createat = time();

$str = “email={$email}&userid={$userId}&createat={$createat}&noisy={$noisy}&apikey={$apikey}”;

$sign = md5($str);

return $sign;

}

/*判断签名是否正确*/

function check($email,$userId,$noisy,$createat,$sign){

$str = “email={$email}&userid={$userId}&createat= {$createat}&noisy={$noisy}&apikey={$apikey}”;

//如果是俩天以前发的则直接认为过期

if($createat+3600*24*2<time()){

return false;

}

return $sign== md5($str);

}

1.5、长期在线及单点登录

1.5.1 长期在线的实现方式

长期在线的实现方式很多，其中一种可行的方式是用数据库存储session,此时数据库基础表需要做响应扩展，相应的流程如下。

用户第一次登录，系统侧登录成功后返回token,同时服务端将token和用户ID以及响应授权进行关联，此时客户端将token存储起来。以后，每次访问新的页面时，我们都只要携带该token即可。服务器端通过token识别该前端是否授权。一般地，为了安全,我们建议添加过期时间字段，用于刷新oken。长期在线相关表结构如下：

1.5.2 多点登录和单点登录

多点登录的本质可以理解成account_session 表中，1个userid 对应多个token,单点登录即一个userid 只能对应一个token.那么问题简单了。假设我们系统配置了单点登录，则用户A登录成功后获取了token1,用户B也使用了同样的帐号，登录后获取了token2,此时token1自动过期。多点登录则不会过期。此时token1和token2同时生效。

对于该表，我们要定期清除，因为随着我们系统访问量增加，该表记录会累计越来越多，最后数据库臃肿，定期清除可以给数据库减肥。另一方面,定期清楚可以增强系统的安全性。

定期清除的策略很多，可以根据lastoptat字段清除，每次用户登录的时候，我们存储用户的登录时间到这个字段，如果检测到用户最近一次登陆时间相隔一定时间，则清除该记录。另一方面，如果bindat时间超过多长时间，则我们重新减除绑定关系。这些定时操作一般在后台进行。

多个设备同时在线是特殊情况，可以简单理解为设备ID即为token。