多端登录设计

现在人们都处在一个多端和多设备的世界中，首先要区分多端和多设备的概念。多端是指一个系统可能开发了PC端、App端、Pad端、微信端、小程序端、车载端等。多设备是指不同的硬件环境，如3个手机、2台计算机、2个Pad。

对于多端应用的开发可以采用混合开发模式和跨平台方案实现，否则就需要安卓、iOS、H5多种工程师共同介入开发。

4.6.1 多端应用的开发模式

1.客户端开发模式

客户端需要面临H5、安卓、iOS、小程序、公众号等多种运行环境、多种开发语言，这就需要有不同技术方向和能力的工程师，人员成本和时间成本都比较高。因此，很多企业都采用混合开发模式和跨平台方案实现。

（1）混合开发模式。

混合开发是现在应用最广的模式，具有体验好、成本低、速度快的特点。对于App的一级页面采用安卓和iOS原生开发，提升用户体验；对于App的二、三级页面采用H5开发，提高开发效率，便于后期维护和升级。

H5的开发比重大于原生，由于H5运行在不同的环境中，页面展现形式和功能都会存在一些差异，因此H5无法避免要进行环境信息判断。

如图4-21所示，安卓端、iOS端都要为H5提供统一的API进行信息封装，获取当前所处的环境信息，如操作系统、版本、机型、品牌等信息，对于用户的登录信息、业务信息也可以通过这种方式来进行传递。H5通过判断所处的环境信息不同，而进行不同的页面展示。

图4-21 App混合开发

Pad端、微信端也是相同的原理，只是微信端是由腾讯的JSSDK提供API服务而已，本质都是相同的。

（2）跨平台方案

跨平台方案的目的是让开发人员只开发一次，打包出来的程序却可以运行在不同的环境中，达到一次开发到处运行的目的，同时带来接近原生的使用体验，类似的产品正在不断发展，下面介绍使用较多的两个框架。

①     Flutter框架：Google的开源项目，可以让开发者使用一套代码高效地搭建多平台应用，支持移动端、Web端、桌面端和嵌入式。Flutter 开源、免费，非常适合商业项目和个人项目。

②     uni-app框架：主打一次开发，多端覆盖。使用Vue.js 开发所有

前端应用的框架，开发一套代码可发布到iOS、安卓、H5、各种小程序

（微信/支付宝/百度/头条/QQ/钉钉/淘宝）、快应用等多个平台。

2.服务端开发模式

服务端开发模式有两种：独立服务端模式和整合服务端模式，如图4-22所示。

（1）     独立服务端模式：每种客户端都对应独立的服务端项目，缺点是大量的重复开发，复用性较差，但是能够很好地支持各端个性化需求，隔离性高，不会相互影响。例如，安卓端的服务故障，不会影响iOS端使用。

（2）     整合服务端模式：所有服务端聚合在一起，同时支持多端应用，优点是复用性强，降低开发量，缺点是各端个性化需求可能相互影响，增加实现的复杂度。

图4-22 独立服务端模式与整合服务端模式的对比

整合服务端模式显然更加合理，可以提高产出效率，节约成本。

但是，服务端经常要根据不同的客户端执行不同的流程，怎样区分呢？以注册为例，数据表中需要新增注册来源、注册方式字段，如表4-

2所示。

表4-2 用户信息表新增字段

这就要求接口在请求时，必须携带注册来源、注册方式字段。这种方式的弊端是需要不断维护注册来源的编码，甚至修改程序代码。

而应用信息配置设计，是一种扩展性更强的方案，思想来源于多租户的开放平台设计理念，将每个客户端进行定义，为其分配唯一标识符。将此标识符放在所有的请求信息头上携带，以供服务端进行判断，同时还可以起到安全控制的作用。应用信息配置部分字段如表4-3 所示。

表4-3 应用信息配置部分字段

利用应用配置信息设计，整合服务端模式交互流程如图4-23所示。

（1）     客户端请求服务端时，在请求头上携带SecretID，客户端配置信息一般会加载到缓存如Redis中，提高查询效率。

（2）     服务端从请求头中获取SecretID，然后从Redis中查询完整的应用信息。

（3）     判断应用的类型为PC、安卓、iOS等，然后执行不同端的个性化业务。

（4）     给客户端应答。

图4-23 整合服务端模式交互流程

4.6.2 多端应用的会话保持

当使用Token模式替代传统Session时，过程如图4-24所示。客户端发起登录请求，服务端验证通过后，生成全局唯一的Token，绑定用户信息，并将Token作为Key存入Redis中。Token模式详细设计可参见5.8 节。

图4-24 多端应用会话保持

对于多端应用，在设计时Token的存储需要进行隔离，否则在Redis 中无法区分Token属于哪个应用，从而造成一些需求无法实现。

场景举例：当同一个用户从App端、PC端、微信端登录后，Redis 存储如表4-4所示。

表4-4 Token未隔离存储

各端的Token不同，而用户信息相同。如果此时想要只将App端的全部用户踢出（清空App端的Redis数据），则无法做到，因为无法区分哪个是App端使用的Token。所以，服务端在存储Key的过程中要与 SecretID进行组合存储（Key=SecretID+Token），Redis存储如表4-5所示。

表4-5 SecretID+Token隔离存储

这样，只需要清空以“APP#”开头的所有Key即可完成App端全部用户的踢出操作。

同理，需要针对某一个用户踢出，如果用户同时登录了App端、

PC端，则全部踢出，只需要再加上用户ID作为Key进行存储

（Key=UserID+SecretID+Token）即可，Redis存储如表4-6所示。

表4-6 UserID+SecretID+Token隔离存储

这样，清空以“1001#”开头的所有Key即可完成1001用户在所有端的踢出操作。

多设备登录设计

多端应用一般是允许同时登录的。例如，QQ的同一个账号可以同时登录PC端、手机端、Pad端。而相同端的不同设备则是不允许同时登录的。例如，同一个微信号在手机A上登录了，在手机B上再登录，则会自动把A设备踢出，这种设计更多的是出于安全性考虑。

如图4-25所示，模拟电商类App，使用相同账号在两个手机上进行登录购买的流程。使用A手机购买某商品，但是并未支付，还停留在支付页面。 使用B手机找到这笔未支付的订单进行支付，支付成功。这时回到A手机上再点击“支付”按钮，如果服务端控制不当，就会造成数据异常，甚至造成用户重复支付。

图4-25 多设备登录的问题

因此，交易类系统通常不允许多设备登录，增加了单设备绑定和踢出功能，账号踢出详细设计可参见5.2节。

但是，某些工具类软件或系统是允许多设备登录的，在用户首次使用一个新设备登录时就会提示用户“是否信任该设备”。设备授信原型如图4-26所示。

图4-26 设备授信原型

授信就是授权并信任的简写。设备授信设计主要有两种：一种是非联机授信，另一种是联机授信。

1.非联机授信

非联机授信主要依赖在设备上存储的授信文件，而不需要与服务端建立连接。首次授信与非首次授信存在一些区别，但是整体流程相同，如图4-27所示。

（1）非联机授信，首次使用新设备流程。

①         用户在某设备登录。

②         登录成功后，检查本地是否有特定的授信文件。授信文件以加密方式存储，文件中包含被授权的用户信息、设备信息、授信方式。

③         如果本地没有授信文件，则弹出提示，询问用户是否信任该设备。如果用户信任该设备，并且完成授信认证流程，则会将用户信息、设备信息、授信方式进行加密存储为授信文件。下次再使用该设备时就可以不需要再次询问。

（2）非联机授信，非首次使用流程。

①     用户在某设备登录。

②     登录成功后，检查本地是否有特定的授信文件。

③     如果本地有授信文件，则读取文件并解密，取出文件中的用户信息、设备信息、授权方式信息进行比对。如果比对无误，则可以正常使用。

图4-27 非联机授信流程

C/S结构基于本地文件的授信，B/S结构可以将授信记录写入

Cookie中。因此，非联机模式的缺点就是授信内容可以被删除，一旦删除就必须进行重新授信。

由于授信文件存储在客户端，所以也存在被破解和篡改的风险。因此，一定要采用较为复杂的加解密方式，如采用证书、动态秘钥等方式。

2.联机授信

联机授信需要有服务端的参与，授信流程如图4-28所示。

（1）     用户完成系统登录。

（2）     客户端提交设备信息、用户信息，向服务端查询设备授信情况。

（3）     服务端检查授信记录，发现用户没有信任过该设备，则返回无授信记录。

（4）     客户端询问用户，是否需要信任并使用该设备及授信方式是什么。

（5）     用户选择授信方式，完成授信认证流程，并提交客户端。

（6）     客户端将授信方式、用户信息、设备信息提交给服务端，服务端存储授信记录。

图4-28 联机授信流程

非联机授信的优点是实现简单，缺点是授信文件存储在设备上，存在被破解的风险，所以一定要使用加密和签名的手段，防止文件被篡改或伪造。联机授信的优点是授信记录存储在服务端，具有更高的安全性。

如果询问用户是否信任该设备，用户点击“信任”按钮，则完成授信。联机授信和非联机授信都必须完成授信认证流程。

当用户点击“信任”按钮时，服务端会向用户的注册手机发送短信验证码，只有用户输入正确的验证码，才可以添加信任设备。

这样就保证了如果用户账号和密码丢失，则在其他设备登录时也是不可以使用的。App端应用经常采用短信方式验证，而PC端则可以采用短信或邮件方式验证。

授信方式是用户对设备信任程度的选择，一般有永久授信、单次授信、区间授信和IP授信。

（1）     永久授信：是指永远信任该设备，只要授信记录不丢失，无论重复登录多少次都不需要再次授信。

（2）     单次授信：是指仅在本次信任该设备，退出后再次使用此设备登录，还需要再次授信。

（3）     区间授信：是指用户可以指定一个时间段，如信任该设备1 周、1个月。过了这个时间区间，依然需要再次授信。

（4）     IP授信：是指信任同一个本地网络的所有设备。这样，用户就可以在同一个信任IP地址下的设备上登录账户。

多设备登录时，需要将客户端设备信息尽量完整地记录下来。因为很多的系统问题都是由兼容性问题引起的，便于排查问题，设备信息如表4-7所示。

表4-7 设备信息