我个人开发过程一般是和产品说,『你们提业务要求、交互方式、性能要求等就好,技术方案我们会综合开发时间、系统架构等因素考虑』。
恰好我之前也花过几个小时做过类似的验证登录过程,这里作为探讨,把产品同学的回答做个引用,解释一下其中『不技术』的地方。
1. 每打开一次微信网页版页面的时候会随机生成一个含有唯一 uid 的二维码,每次刷新页面都会不一样(这个可以保证一个 uid 只可以绑定一个账号和密码,如果一个 uid 可以绑定多个账号和密码,那么很可能你的电脑会登陆别人的微信哦);
确实返回了唯一 id,但目的是为了识别用户身份,而且实际上打开这个页面的时候浏览器已经和 Server 创建了一个长连接等待确认信息。
查看的源码可以轻易看出来,其实这个页面加载完毕的同时,也已经把很多登录后才需要的相关资源都加载进来了,然后会开启一个长连接等待登录用户的信息。
2. 当用户使用登陆后的微信扫描该二维码的时候,会将这个 id 和手机上的微信账号及密码绑定,并上传到微信网页版服务器;
先上个图:
二维码样例:/x/ARmFYVvUzczwBl9u6Y1I,利用我查查之类的二维码应用可以轻易得到类似这样的地址,但并不会自动打开该地址,微信实际上针对/x/开头的地址做了特殊处理,会自动获取相关信息并提示确认。 在手机版微信访问这个页面进行确认时,Server 已经同时获得了客户端信息,并通过之前保持的长连接告知浏览器。
3.微信网页版页面每隔 1 秒或 2 秒会 get 请求该 id 对应的微信账号及密码,如果 id 绑定上了微信账号和密码,那么就可以请求到账号和密码,就可以自动登陆了。
浏览器展示完长连接里包含的用户信息(头像等)后,会新开一个长连接等待客户端的确认操作,其 URL 类似https://login./cgi-bin/mmwebwx-bin/login?uuid=794ecedd804f47&tip=1&_=1395748413642。从安全的角度来说,无论如何都不会让客户端获得微信帐号和密码,要知道,密码这玩意腾讯自己都不敢保存(有兴趣的同学可以自行了解下 CSDN 明文密码泄露事件),肯定是不可能返回给浏览器的。
而且从体感来看,怎么着都不可能是页面 1-2 秒 GET 请求的,实际是通过长连接,近乎实时的获得信息。 对于验证过程,Open API 一般是通过授权令牌(Token)来解决的,原理是当用户通过授权后,分配一个限定条件下的令牌(如限制本机访问、限制授权有效时间、限制同时登录设备数等),使获得授权的用户仅在有限的前提下能访问相关服务。 像计算机休眠后曾做的授权就自动收回了,这样就有效的避免了在别人电脑上(尤其是网吧)打开,但忘记关闭或退出这类安全问题了。
同时,整个授权过程的验证部分在手机端进行,有效杜绝了 PC 上泛滥的各类木马、『安全工具』的监听,大大降低了帐号被盗的风险。
整个核心过程是:浏览器获得一个临时 id,通过长连接等待客户端扫描带有此 id 的二维码后,从长连接中获得客户端上报给 server 的帐号信息进行展示,并在客户端点击确认后,获得服务器授信的令牌,进行随后的信息交互过程。 在超时、网络断开、其他设备上登录后,此前获得的令牌或丢失、或失效,有效完成了安全防护。
from:/story/3783725
from:/question/20368066