[技术博客] 小程序扫码登陆网页端原理

目录

• 1、问题引入
• 2、几个难题
  • 1. 网页端是怎么知道哪一个用户扫描的二维码？
  • 2. 小程序扫码，扫出来的是什么东西？
  • 3. 小程序扫到二维码之后，作了什么事情，怎么和网页端通信的？
• 3、解决方案
  • 1. 相当重要的uuid
  • 2. 用户信息与uuid的绑定
  • 3. 网页端轮询uuid，直至获取到用户身份信息
• 4、一些技术细节

做者：雨飞

1、问题引入

在设计用于管理社团信息的网页端时，咱们须要解决的一个问题是怎样让社团管理员很方便地登陆到管理平台中去。出于提升用户体验角度的考虑，咱们的小程序在用户第一次登陆时，只须要微信受权得到身份信息，就能够自动完成注册和登陆流程，用户无需手动输入密码或建立新的帐号，一切都是与微信绑定的。这种作法当然方便，但缺点在于登陆流程和微信环境高度绑定，脱离微信环境以后再想获取并验证用户的身份信息就比较困难。

最后咱们选择了在网页端设置小程序扫码登陆，用户只须要打开咱们的小程序，在“个人”页面中点击“扫描二维码”，即可以自动登陆到网页端社团数据管理平台。在实现这个功能的过程当中，咱们遇到了一些问题，这些问题在经历了一段时间的学习研究以后得以解决，咱们以为有必要在此把解决问题的过程记录下来，做为技术博客。所以有了这篇文章。

2、几个难题

1. 网页端是怎么知道哪一个用户扫描的二维码？

这是不少人在第一次看到”扫码登陆“这种登陆方式时的第一反应。的确，这个过程看起来有点神奇，网页上只是显示了一个二维码而已，为何小程序扫码以后，网页端就知道是哪一个用户扫描的二维码呢？若是咱们要本身去实现这个功能的话，也必然面临着一样的问题。

2. 小程序扫码，扫出来的是什么东西？

第二个问题其实是由第一个问题引出的。既然网页端不须要任何额外信息就能知道是哪一个用户扫描的二维码，那么二维码里就必然包含着对识别用户身份相当重要的信息。这里面的信息具体有哪些内容？这也是咱们着重要解决的事情。

3. 小程序扫到二维码之后，作了什么事情，怎么和网页端通信的？

从用户体验的角度来看，小程序扫码登陆是一件十分天然的事情：网页端显示二维码，小程序扫码，网页端即可以正常登陆。然而小程序扫码以后，网页端怎么知道小程序已经扫码了？小程序是如何把自身存储的用户信息发送给网页端的？只有解决这些问题，扫码登陆的流程才能够说是被真正打通。

3、解决方案

1. 相当重要的uuid

uuid（通用惟一识别码）是解决以上难题的关键。其实扫码登陆的根本难题在于如何在小程序和网页端之间共享用户的身份信息，所以势必须要一个识别码来进行网页端和小程序的通讯绑定。

后端服务器对外提供一个接口，网页端每次访问这个接口，都会得到一个全局惟一的uuid。网页端获取uuid以后，将其转换为二维码展现在页面上，二维码包含且只包含这个uuid。

咱们使用了qrcode.react做为网页端生成二维码的组件。

2. 用户信息与uuid的绑定

后端服务器生成uuid以后，便会将这个uuid存入redis缓存中。小程序扫描到带有uuid信息的二维码，得到用户身份信息以后，访问服务器的另外一个接口，将用户信息和uuid一块儿发送给后端。后端把身份信息与刚刚存入redis的uuid绑定在一块儿，由此完成用户信息和uuid（也即二维码）的绑定。

3. 网页端轮询uuid，直至获取到用户身份信息

网页端知道，在将来的某一时刻，小程序会把当前登陆用户的身份信息和uuid绑定在一块儿，所以网页端只须要不断轮询后端服务器，并把本身的uuid做为参数，就能够知道uuid是否已经绑定了用户信息。若是还未绑定，则等待直至uuid失效；若是已绑定，就使用该身份信息登陆。至此，扫码登陆的流程所有打通。

4、一些技术细节

1. redis在存储uuid时，出于安全考虑，必须设置过时时间
2. 网页端轮询时，须要注意轮询时间间隔，避免对服务器形成过大压力
3. uuid一旦与用户身份信息绑定，一次使用后则需失效，不然会带来安全隐患