微信PC扫码登录和支付分析

一、PC扫码背景

随着手机的普及，越来越多的人习惯在手机上体验PC端的应用，例如微信的网页版和手机版就是个典型的例子。同时手机端的安全性相对于PC，售票机等外部环境会高很多，且方便很多。所以扫码功能越来越被人们接受，并广泛运用于生活中的各个场景，例如：扫码买地铁票，扫码登录CSDN网页等。

那么扫码是怎么实现的呢？它是如何在PC端和手机端进行同步，以达到一端登录，登录everywhere呢？

二、扫码操作实现假设

场景分析：以微信公众号扫码登录举例：当我们进入微信公众号网页登录进去时会提示需要手机扫码验证（微信公众号网站），手机端扫码并在手机端确认后，网页自动跳转到登录成功后的管理后台了。整个过程看起来很简单，没有弹出管理员账号密码输入框，扫扫码就授权了，而且手机在自己手中，安全性自然也高了很多。又简单，又安全，无怪乎PC扫码这么流行了。

角色分析：仔细观察整个过程你会发现有这2个角色：公众号页面，手机。做为程序员我在脑补2个：公众号后台服务，微信手机后台服务，这两个是分别为2个前端服务的。那么猜测整个PC扫码过程应该有4个角色参与。

扫码关键问题点：

• PC如何和手机端通信的呢，如何同步手机端信息呢？
• PC的二维码安全吗，会不会窃取我手机的内容？
• PC的二维码能保证是否有效吗，例如这个二维码已经过期了，无效了，但我扫码支付完才发现没充值成功，导致损失？

带着这三个问题，我们分析一下微信扫码的具体实现吧~

三、微信公众号扫码登录分析和验证

1、PC的二维码能保证是否有效吗，例如这个二维码已经过期了，无效了，会不会出问题？

我们刷新微信公众号的二维码页面会发现每次刷新后的二维码图片都不一样，所以微信的每个二维码都是表示一个唯一的操作，每次刷新这个操作都会改变，保证同一时刻在不同的PC端都是唯一的。且二维码一段时间后会显示已经失效，如下图所示：

2、PC的二维码安全吗，会不会窃取我手机的内容？

通过扫码软件解析这个二维码，发现这个二维码对应的字符串格式如下：

这个二维码字符串中没有任何敏感信息，只有一串晦涩难懂的16进制字符串。且这个二维码格式是特定的，如果有人伪造二维码，他只能伪造这个格式，但是无法伪造这个16进制串，因为这个串是有服务器生成的，绝对不可能是PC网页生成的。所以你的扫码是绝对安全的。

3、PC如何和手机端通信的呢，如何同步手机端信息呢？

题外话：java中有个概念叫面向对象编程，官方解释如下：

面向对象程序设计(Object Oriented Programming)作为一种新方法，其本质是以建立模型体现出来的抽象思维过程和面向对象的方法。模型是用来反映现实世界中事物特征的。任何一个模型都不可能反映客观事物的一切具体特征，只能对事物特征和变化规律的一种抽象，且在它所涉及的范围内更普遍、更集中、更深刻地描述客体的特征。通过建立模型而达到的抽象是人们对客体认识的深化。

那么我们用java的类图猜测一下第二节提到的四个角色的关系：

首先PC端和手机端无法直接通信的，那么他们之间需要有一个中间角色来帮助完成，那就是他们各自对应的后台服务（PCServer, MobileServer），这两个后台服务之间是可以相互调用的，于是我们猜测他们之间的关系如下：

• PCClient: 微信公众号网页，主要职责是轮询PCServer查询操作的结果
• QRCode: 二维码，有自己的有效期。过期后的二维码是扫描不成功的
• PCServer: 对接PCClient，主要响应PCClient的轮询请求，并接收MobileServer的信息推送
• MobileServer: 手机端的业务服务器，处理客户端的登录，支付等业务请求
• MobileClient: 手机客户端，包括扫码等手机端功能
• Camera： 摄像头，被手机端app调用（例如：微信调用摄像头的扫描二维码）

为了验证这个猜测，我们需要验证以下几点内容：

• 微信公众号网页二维码被扫码后如何获取到手机端的状态同步？
• 如何确保是否通信的安全呢？
• 二维码失效是否也是服务器管理的呢？因为服务器相对客户端会安全很多

1、验证微信公众号网页二维码被扫码后如何获取到手机端的状态同步

从chrome的“开发者工具”我们发现该页面每一秒中向https://mp.weixin.qq.com/cgi-bin/loginqrcode?action=ask&token=&lang=zh_CN&f=json&ajax=1 发送一次GET请求。从这里我们可以断定微信公众号的二维码页面是通过轮询的方式向服务器获取手机端上传的信息来和手机端做信息同步的。

查看该请求的header我们发现下面的信息：

从这个请求的Response Headers中还发现这个每隔1秒的轮询的连接方式是 keep-alive，这个其实确保了我们每隔1s的请求是在一次服务器的连接中，提升了轮询的效率，避免频繁的请求导致服务器负担很重。带有keep-alive和不带keep-alive的http请求对比如下，普通不带keep-alive的请求每次完成后都会自动断开，在请求很频繁的情况下客户端和服务器的负担都会很重，严重的会导致服务器down机：

2、如何确保是否通信的安全呢？

这个请求的url是https的，且它的Response Headers里面显示Strict-Transport-Security ，告诉浏览器这个url只能用https访问。那么这里我们可以说二维码扫码是相对很安全的了。

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS)  lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

3、二维码失效是否也是服务器管理的呢？因为服务器相对客户端会安全很多

观察微信公众号二维码页面的轮询请求，一段时间后会停止请求，此时页面会显示一个该二维码已经失效的提示文案。通过查看最后一个轮询请求的response，我们发现该请求的response较之前有些不同，此时的status为3，所以可以猜测二维的有效期校验是在服务器处理，当PC轮询一段时间后发现该二维码失效了就不再继续轮询了，并提示用户该二维码失效，需要重新刷新二维码。

四、扫码流程总结

通过上面对微信公众号平台的扫码流程分析，我们大致可以总结一下扫码的流程如下：

五、扫码其它操作套用

同样的这套扫码思路可以套用到其它的扫码业务，例如：扫码支付，扫码关注等等。不同点在于生成二维码的唯一id对应在服务器的数据信息会不同（也就是微信的qrticket的映射信息会不同），同时该二维码的操作类型（action）也会不同。

好了，以上是对PC扫码这个技术的分析和总结，不正确的地方欢迎提出宝贵建议~