转载： https://zhuanlan.zhihu.com/p/56040461
上一篇文章《selenium的检测与突破》讲过了如果绕过对于webdriver的检测。
接下来就可以登陆了吗？别高兴太早：
无论我使用’find_element_by_id’还是’find_element_by_xpath’，当输入密码时候都会出现“哎呀出错”的滑动验证码。想必大家都会被此困惑。
于是乎，我通过邪恶F12 发现每当用户名发生变更之后，点击密码输入框，就会出现一个POST请求，两个参数：一个username，另一个是一大串的ua，返回一个{“needcode”:“True”} ，诶？好像懂了一些，于是，测试不使用selenium的正常登陆，返回的值的False。嗯，又懂了一些。
那么问题来了，这一大串ua怎么搞？
If you can ,受小弟一拜!
于是，我尝试使用上文的代码注入思想，能不能偷梁换柱，将True改为False，对不起，没好使。
经查阅资料，这一大串ua，不仅包括着浏览器指纹，鼠标轨迹，等等等，并且，算法不止一套。
最后，还是老老实实尽量去模拟真人操作吧：
控制变量法：
第一回合：
通过’find_by_element_'输入账号密码后，并且sleep随机时间，手动滑动验证码，无论怎么滑，刷新多少次都是“哎呀出错了”→刷新，继续手动输入账号密码，手动滑动验证码→死循环——很委婉的验证失败。
所以，那些网上说滑动验证码，要分段，或者通过速度曲线去滑，都是次要的。因为已经检测出来是机器人， 只是通过这种方式很委婉的告诉你被反爬了，败北。
第二回合：
把‘find_element_by_’统统注释掉，采用ActionChains，并且来一些障眼法——做一些鼠标移动的假动作，败北。
第三回合：
仅仅通过selenium+mitmproxy+chromedriver 去启动浏览器，然后手动去输入账号密码，哎？没弹验证码，并且点击登录，成功了？？？？
因此我断定，这第二关是行为反爬
继续科学上网，其实chromedriver会将下图中的JavaScript文件注入浏览器。
于是我的猜想：
1.通过sleep随机时间，排除了操作过快的原因。
2.find_element_by和ActionChains都是会被检测的。好像是selenium会开启一个本地代理，所有的浏览器自动操作都会用这个代理进行，find_element方法就与selenium代理进行了通信，不知道js是怎么知道selenium的准确代理地址并知道进行了通信。并且他们也许检查有chromedriver的js执行引起的修改。
3.通过具有偏移量的元素来检测——通过selenium点击一些带有偏移量的元素（按钮）仍会引发。例如从扫码登录切换到账号密码登录的按钮。我想阿里对于自然用户行为肯定有一番研究的。
ok，通过低效的最笨的方法，按键精灵思想，来模拟：
我来写一个shell脚本，通过像素点坐标，从驱动层模拟键盘鼠标的操作，绕过检测。
成功了！
但是此方法效率低，并且限制也比较多，例如屏幕大小和分辨率不可随意变更，不支持headless。
shell的代码就不公布（因为我不知道您的使用意图）。很简单，但思想必须到位。
ps：留言评论我都会认真看的，另外有更好的想法可通过[email protected]与我取得联系方式交流。