微信网页版登陆解析

网页版微信解析实践

前段时间，刚好遇到朋友拜托我做一个功能。大致的功能需求中，有一个重要部分，是需要监听微信的消息，并收集起来，之后再根据一些需要对数据进行处理。（我会在文章的后面附上相应的源码, 如果有说错的地方，还请看官勿喷。 ）

于是，很正常的上网搜索，发现网上关于微信接口方面的资料，主要集中在公众平台和安卓方面的 sdk ，明显不符合需求，剩下的唯一方式，就只能通过官方的微信网页版了。

为此在网上经过多次搜索，目前只发现有如下两篇文章讲到网页版微信的解析：

http://www.woyaofeng.com/1421.html

http://www.tanhao.me/talk/1466.html

可惜的是，根据实际观察分析，发现与目前官方的情况已经有很明显的出入了，不过，还是很有参考的价值。

但最终，这活还是得自己去研究。

现根据自己研究的情况，写出大致步骤，希望对一些有兴趣的同学，能有所帮助。

先做一些铺垫。由于官方的登陆实现要求，是必须先用手机扫描过二维码之后，由手机在终端授权登陆后，网页版才会进行一些相应的动作，比如收集交互时的认证信息。

也就是说，网页版的登陆，可以大约分为这么一个过程：  

         1.登陆主页后，会生成一个UUID，你懂的，这是个唯一性标识。

             GET "https://login.weixin.qq.com/jslogin?appid=wx782c26e4c19acffb&redirect_uri=https%3A%2F%2Fwx.qq.com%2Fcgi-bin%2Fmmwebwx-in%2Fwebwxnewloginpage&fun=new&lang=zh_CN"

    2. 根据该 UUID 去请求相应的二维码信息。

    GET  "https://login.weixin.qq.com/qrcode/{uuid}?t=webwx";

          3.通过浏览器端不断的轮询，以确定手机是否已经完成授权，并允许用户在浏览器端的登陆。

          4.   GET "https://login.weixin.qq.com/cgi-bin/mmwebwx-bin/login?uuid={uuid}&tip=1&_={time}"; --这里的time其实就是一个System.currentTimeMillis().

          5.  如果手机端已经授权通过，则会在第3步中，返回一个响应的内容，返回的响应中会有window.redirect_uri=https://wx.qq.com/xxxxxxxxxx(URL地址)类似的信息。

          6   通过再访问第 4 步中的 URL ，得到真正的、最后的登陆 URL 地址。如 https://wx2.qq.com/xxxxxxx 。之后通过查看，发现第 4 步和第 5 步其实主要是域名不同，估计是官方由于某种原因（升级之类的吧）。所以实际操作中，可以直接替换掉第 4 步中的域为 wx2.qq.com 即可，第 5 步就可以省略了。

         7.   一旦在第 5 步中，正确的登陆成功后，必须保存服务器端返回的cookie 信息，之后 cookie 信息都会用于后续的交互。

   至此，就完成了基本的登陆认证过程，看着比较麻烦，其实想通了，自然也就觉得没啥了。如果让你去这一块的登陆授权验证，估计也会大致这么一个思考的方向。

   既然登陆了，自然就要涉及二个字：交互。 交互的话，自然免不了要考虑如下几个内容：

         a.  登陆后，需要一些初始化的数据信息内容，数据的请求格式，相互校验数据信息。

         b.  获取用户列表信息。

        c.    怎么保持浏览器端与服务器端的心跳，需要传递什么样的数据信息，这些数据信息是每次心跳之后，都会改变，还是说，一直不变，或者是一定心跳次数后，就会更新？

    d.  由于网页版的登陆，需要手机同时登陆在线，那么是不是有可能需要浏览器端定时向服务器发送与手机端的状态同步心跳 ?

   慢慢来，毕竟，这玩意并不复杂，就是有点繁琐。

       1. 在之前已经成功登陆的基础上，需要做一些初始化工作，POSThttps://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxinit?r={time}&skey= ，该请求返回的数据中需要关注的内容有：SKey，SyncKey，这二个会在之后的交互中，经常用到，当然也包括此前登陆得到的cookie信息。

      2. POST  "https://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid={sid}&r={time}&skey={skey}";

         从URL的命名来看，应该是向服务器端提供的一次验证，而且这次验证在返回的json中的syncKey将会做为此后心跳机制中的交互码。在上一步中也会返回此码，二次得到的syncKey并不一样。而且本步骤得到的syncKey中的数据总是比上一步骤的数据要多一个。

  3. 对浏览器端与手机终端做一次状态同步心跳。

   POST "https://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxstatusnotify?r=1397443950116&skey=%40crypt_cfbfba84_e5913dbec2b764d086b7d1d1aab946ca";

  4. 浏览器端与服务器端的定时心跳。

    GET "https://webpush2.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?skey={skey}&callback=jQuery183008612365838727565_1397377003545&r={r}&sid={sid}&uin={uin}&deviceid={deviceid}&synckey={synckey}&_={time}";       

    该请求有二个作用，一个是用于保证心跳，一个是用于暗示是否有相应的微信消息。返回值的内容大致如下： {retcode: ” 0 ″ ,selector: ” 0 ″ } 。通过观察发现，当 selector 不等于 0 的时候，意味着需要客户端发起请求去获取消息，这时，需要重新请求第 2 步骤即可。

    大致的情况如上所述，建议有兴趣的同学，请结合文章开头引用的两篇文章，毕竟，本文主要是对其做一些补充说明。

（备注：自从去年去了一家港资公司之后，基本上也没怎么写过代码了，感觉生疏了许多。刚好这次借着机会，练练手，同时把 gson 和 httpclient4 的东西学习一下。）