轉載： 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：留言評論我都會認真看的，另外有更好的想法可通過cheezeleo@163.com與我取得聯系方式交流。