昨天搞的是微信登录,今天我们要来搞一下qq登录!

但作为过来人,我想假装平静的说出心声:为啥同一个公司的两个产品系,文档质量就他奶奶个抓儿差那么多呢?

如果说昨天搞微信很嗨皮的话,那么今天搞qq真的想在吃翔,我这暴脾气,唉~

当然,这篇文章并非只是来吐槽的。言归正传,整体思路还是和微信第三方登录一致,我就不细说了,有兴趣的朋友可以看之前的那篇文章。

我们接下来还是主要来关注qq登录接口不同于微信的地方!(文档,文档,渣文档就是最大的不同!妈蛋~)

先来看一下官方文档,如果你打开显示的是404错误,请多刷新几次,具体原因不清楚哇~

文档一开始也正儿八经的给我们解释了解释OAuth,我们可以直接跳过啦~关键要注意的是它通过第1步得到的code换access_token的接口,也就是 “https://graph.qq.com/oauth2.0/token“ 这个接口,它并不是像微信那样走的rest风格的服务,而是又借住了一次重定向来完成的!

这尼玛怎么搞的?这多出的一跳不仅让你蛋疼,而且也丢失了state参数,这让我们这种不依赖cookie来存sessionid的人肿么办?

如果你是phper,那么curl的CURLOPT_FOLLOWLOCATION可以让你的请求跟踪这次重定向,但我用nodejs的restify相关实现是无法正常的接受重定向响应的!

所以我只能自己解析响应头,取出这个url,当然我们就不用傻傻的请求这个url了,因为该url里就已经携带了我们需要的access_token!这也使得我们在获取Code时前台传递的用户会话id不会丢失,因为我们并没有跳走嘛~~

然后我们再来看看关于获取用户openid的操作(https://graph.qq.com/oauth2.0/me),该接口竟然是根据jsonp机制返回的,这尼玛是多久前的啊?

所以我们需要自己去解析返回内容,这里我需要特别叮嘱的是,js平台(包括nodejs)下尽量避免使用eval函数,还是老老实实的正则匹配吧,不然,你懂的!

代码我已发到gihub上,有兴趣的童鞋不妨去看看~