扫码登录项目实践 背景说明随着移动端应用的普及，扫码登录在日常的登录认证过程中已经非常普及了，在提升用户便利的同时，由于减少了账号密码的输入，在一定程度上也起到了增强安全性的目的。随着控制台产品的迭代，PC端界面及功能已趋于稳定，考虑到目前移动终端更便于用户使用，经过公司内部层层审批，控制台移动端的项目顺利立项。作为充分为用户提供便利的移动端应用，扫码登录功能便自然的纳入了起基础功能。登录认证的本质扫码登录本质上也是一种登录认证方式。既然是登录认证，要做的也就两件事情！告诉系统我是谁向系统证明我是谁比如账号密码登录，账号就是告诉系统我是谁， 密码就是向系统证明我是谁;比如手机验证码登录，手机号就是告诉系统我是谁，验证码就是向系统证明我是谁;那么扫码登录是怎么做到这两件事情的呢？扫码登录过程中移动端是已登录状态，这两件事对移动端而言都是明确的，登录过程中的重点是怎么把移动端的登录状态传递给PC端。在这个过程中主要就是通过扫码的二维码了，二维码本质上就是一串具有唯一性的字符串。通过这个字符串便可以将已登录方授权未登录端进行登录了。技术方案根据项目实际情况，参与扫码登录的应用为console-ui、consent、console-biz、app：console-ui :控制台前端，需登录的应用consent :用户认证端console-biz :控制台后端服务app :移动端应用，微信端H5网页实现流程在使用超算云服务控制台应用时，由 console-ui 判断用户是否登录，未登录的情况下将自动跳转到 consent 进行登录操作，本需求将修改consent登录界面，在已有的账号登录基础上增加扫码登录机制，默认采用账号登录方式，当用户切换登录方式为扫码登录时，将调用console-biz提供的接口获取 scanId，使用 QRCode.js 生成携带scanId参数的app端网页认证URL的二维码。用户使用微信扫一扫功能，可直接打开app端的指定页面，在该页面完成用户确认授权操作，consent通过轮询二维码状态接口，当获取到用户在 app端的确认操作后，携带 scanId 参数跳转到 console-ui，在console-ui 调用接口获取用户 token 信息完成登录。整体交互流程如下所示：二维码生命周期码登录的核心是对二维码生命周期的管理，为了更好地理解扫码登录过程，将上图中二维码生命周期相关的核心流程梳理如下：二维码状态数据字典字典项字典值说明未使用1获取scanId时设置初始状态为该值已扫码(未授权)2app端扫码后更新状态为已扫码已授权(登录)3在app授权界面单击“确认授权”已使用4在app端授权界面确认授权，然后在console-ui中获取到用户token后已过期5超过5分钟redis中不存在记录则返回该值取消授权(登录失败)6在app授权界面单击“取消授权”数据存储方案scanId作为整个扫码登录过程的核心，后端需存储scanId整个生命周期的状态值及需交换的用户数据，而每个 scanId 仅有5分钟的有效期，基于 Redis 的过期策略很容易就能实现这个目的，且比关系型数据库在数据存取上有更优异的表现。故本功能模块相关的数据统一存储于 Redis。后端实现方案后端基于现有的console-biz工程添加新的接口用于前端对接，相关接口见“接口设计”章节。前端实现方案在需求中参与前端开发工作的有consent、console-ui、app三端。1、consent：负责登录界面的交互及展示，基于QRCode.js实现二维码生成，轮询获取二维码状态。2、console-ui：在获取到consent授权回调后，通过scanId调用接口获取用户token实现用户在PC端登录。3、app：扫码后直接跳转到app指定的授权页面，进入授权页面后实现。扫码操作的入口有两个：微信扫一扫、app应用首页顶部的扫一扫。使用app应用首页的扫一扫功能需要解析获取二维码URL中的scanId，然后跳转到授权页面进行授权操作。4、单击某功能时使用component组件渲染对应功能的抽屉功能进行显示接口设计后端以 Restful API 方式为前端提供接口，根据项目情况涉及的接口列表如下：获取scanId接口(PC端调用)获取scanId状态接口(PC端轮询调用)app端扫码接口app端授权接口授权成功后获取登录信息接口(PC端调用)效果截图相关功能将在控制台移动端功能上线后，所有并行用户可线上体验。一、PC端截图：1、初始状态：2、刷新时有个 gif加载动图：3、已扫码：4、已失效：5、取消授权：二、移动端截图：1、正常状态：2、已被使用：3、单击取消授权：4、单击确认授权：5、授权操作时二维码已过期：

链接应该在新窗口打开吗 　　从易用性的观点来说，强制在新窗口打开链接，违反了一个用户界面设计的基础原则：应该让用户对他们正在交互的界面有控制权。　　一个友好并且实际有效的界面设计，在用户做操作的时候，总是能让他们按自己的意志做出决定。当用户在使用界面元素的时候，他们必须知道、理解、并且能预料到什么将会发生。这才是以用户为中心的设计。　　有经验的用户，非常强烈的希望由他们来操控整个系统，系统对他们的行为产生回应。　　我自己的浏览习惯是，使用多标签式浏览器，找到要浏览的信息列表页，例如论坛的一个版块，或搜索引擎返回的结果页，然后连续拖拽好几个自己感兴趣的链接让页面在新标签非激活状态打开，然后切换到最选装载完成的标签来查看内容。　　强制新窗口打开链接的主要问题是，没有强制新窗口打开的链接用户可以通过右键菜单或按shift键（在一些浏览器里可以是拖拽）这种比较容易的方法来在新窗口打开，而强制在新窗口打开的链接要让用户在本身窗口打开却不容易（可以拖动链接到地址栏来在当前窗口打开链接），所以强制新窗口打开链接，超越了用户自己的决定，剥夺了用户的控制权。　　对于浏览网站比较熟练的国内用户来说有几个特点：　　1、就算是浏览目的很明确的浏览者，也未必能立即找到完全满足自己需要的信息，搜寻和比较必不可少；　　2、目前的网速和国内的网页体积来说，网页很少能够即点即开般在一两秒钟内打开，所以许多人习惯一次点开多个页面，让等待页面加载的时间集中在一起。　　3、非常讨厌意料之外的弹出窗口。　　我记得在2000年，我刚接触网络的时候，机器配置都比较差，网速却又很慢，一方面我不能打开太多窗口以免占用大多资源让机器反应变慢，另一方面我又不时地打开新窗口，以便同时加载多个页面，选择最先加载完成的页面浏览。　　为了比较准确地控制窗口的数量，我希望每个链接都能够由我来控制是在自身窗口打开或是新窗口打开。　　我的意见是，谨慎地使用新开窗口，并且新开窗口要给予适当的暗示。一个链接是不是在新窗口打开，尽量交给用户来决定。如果他们想在新窗口打开他们会自己去做，不要低估他们的智力帮他们去做决定什么的。　　当你的鼠标移到一个链接上的时候，浏览器并不会提示你是自身窗口打开或是新窗口打开。　　1、要么给新窗口打开的链接一种特殊的颜色或图标；采用ICON通知访问者外部链接是一种很常见的做法。使用css属性选择器或javascript都可以实现对链接的筛选、外观修改。　　2、大部分链接让用户自己按shift键（在一些浏览器里是拖拽）来决定在新窗口打开链接。　　考虑到有一部分刚接触网络的用户，使用浏览器还不熟练，甚至也不知道使用shift键（或拖拽）来新开窗口，所以在一些必需的情况下还是应该强制在新窗口打开链接。　　在以下几种情况下，强制在新窗口打开链接是比较合适的：　　1、链接指向一个本域名之外的网站：如友情链接一 般使用新窗口，新的网站新的窗口，基本上是可预料的。　　2、提供帮助类的链接：如一个购物页面上对支付方式的帮助说明可以新开窗口，如果内容不多的话使用弹出层比新窗口更好。　　3、页面跳转有可能打断一个正在进行的进程：如在注册页面上指向免责条款、版权声明等页面的链接，页面跳转会导致用户正在填写的注册信息丢失。　　4、链接指向一个非HTML文件。例如指向一个pdf文件的链接最好使用新窗口，也许这个pdf会在新窗口直接浏览，也许会弹出文件下载对话框。