3个方法登陆并获得cookie

因为SDL中有一些情况需要维护一些测试账号，所以需要登陆保存大量的账号的cookie状态来做一些事情。

以下的方案都是基于chrome headless的puppeteer，这是一个nodejs的库，有对应的驱动可以去调用chrome，然后完成一些列的功能。

因为当初做过一些自动化登陆 ，所以印象里这个东西可以做的事情挺多的。

在做账号维护的时候，我们要考虑让开发提交账号和密码，还有测试登陆地址。那么登陆的情况很多(默认先不考虑验证码的事情)。

默认的较为通用的登陆框应该是这样的

这种情况，我们通常账号密码一填，验证码一填写就完事了。

(xx.name.matches("用户名")).click()(xx.name.matches("用户名")).type("admin")(xx.name.matches("密码")).click()(xx.name.matches("密码")).type("admin12345")

但是又比如 腾讯登陆是这样的

需要点击下密码登陆才可以，那么在登陆的时候需要xx.click 

然后再uname.click，uname.type。

基于这么多复杂的登陆框，复杂的前端设计，有些登陆框还是ajax产生的，登陆框也不是input元素，而是div(又学了一个小知识吧！)。我就在想，怎么让开发在提交过程中(录制过程中)拿到他填写的元素的name值呢？这里讲一下，我当初设计的是开发填写一个url地址然后就自动生成一个iframe来显示那个登陆地址 然后让开发填写，这样的话要拿到name值就跨域了！

跨域的话。。。

方案一：

在不增加需求的情况下，好像用document.cookie去跨域比较方便，这样的话可以在公司的js cdn服务器上修改文件。在js头部加一句document.cookie='xx.com'，这样任意子域之间相互通信，但是这样会带来很多问题……后来就放弃了 理论上可以而已。

哦日。。。。后来仔细想了下，那这个问题就变成绕过同源策略了？卧槽 那我岂不是要去找个trick来绕过？那我不就是黑客了？那不行，我是好公民。。有办法绕过同源策略我TMD还不如把漏洞提交上去刷一个gmail的hackerone不香吗？果断取消了这个念头。

为啥我执着的要拿到name值？因为你前端可以千奇百怪，但是一般name是固定的。后来想了一下这也是一个脑瘫的想法，用户名或者密码这几个字也不是固定的吗？

嗯，后来想了下只要模糊匹配任意一个元素的几个属性就行了，比如value,placeholder等属性就行了，盲填就完事了。命中个80%不成问题。

方案二：

用chrome插件，但是这个过程要写一个教程一样的东西给开发 ，告诉他们怎么填写，因为插件会倒入各种流量，开发要是在插件开启后又登陆了各种个样的页面，那你会把那些页面都记录下来丢进测试，万一开发登陆了什么xxporn.com，扫描器也不知道。本着上一个工作记录里“简约，简单”的产品设计思路，这样肯定不行的。学习成本太高太复杂。我如果是开发，拒绝填写3个input框以上的东西。

方案三：

回到最开始，只要填写 账号，密码，登陆地址。这个很符合“简约”原则。符合一个产品经理对自己的严格要求。最好是闭着眼睛大脑里想一下就可以自动填写完成。

最后想了一下 还是让开发填写3个数据，然后我们模拟登陆，解决各种奇怪的登陆情况来完成维护，把困难留给自己，这样开发才愿意填写，才可以推动事情落实，形成正能量的循环。当我们登陆完成后把登陆后页面的截图返回给开发，让他确认这个东西是不是成功登陆后的页面。如果是，那么循环30分钟无限去登陆一次就可以了。

Cookie永远都是alive的。

题外话：

Puppeteer的py版本和nodejs版本差不多，功能很强大，拿node版本来说，因为是事件驱动的，所以可以绑定到很多事件上来操作。比如登陆框是需要submit的吧，所以你可以绑定到submit事件来判断是否提交成功，做检查。也可以截获ajax的fetch 方法等，这是因为支持获得js对象的，简单的获取cookie就可以通过获得document对象来获得cookie属性，当然某些cookie的属性是httponly，读取不到，不过你可以用puppeteer的CDPSession来获得，甚至你可以用proxy，你把整个页面proxy 然后submit后可以抓到request的请求和返回，即可拿到完整cookie。

和刚才说的那样，因为事件驱动，对于异常捕获其实也很方便的。有异常就很好写代码了。

本文始发于微信公众号（xsser的博客）：3个方法登陆并获得cookie