這篇要來講去年做的FB粉絲專頁機器人的後續維護心得, 不知道是什麼的可以先看這篇:
說到後續的維護, 最常出問題的就是FB的帳號防盜誤判問題, 因為我的Server是放在日本Azure上, 而因為有些功能沒辦法透過FB的公開API做到, 所以這種情況我是讓程式自己去做login帳號, 藉此取得cookie以及FB csrf token (fb_dtsg), 然後在模擬使用者行為去打fake request來讓FB認為是使用者自己在操作, 藉此達到更多自動化程式可以實現的功能, 像是FB推播等等。
原本以為程式寫好server架好就不用管事了, 畢竟是全自動化的機器人, 可是沒想到噁心的是, 我大概每幾個禮拜~一個月就會被FB ban帳號, 原因是懷疑我的帳號被可疑境外IP登入, 可是問題是我的Azure VM就放在日本, 而FB也沒有白名單可以讓我設, 導致我只能一直被FB的防盜演算法強O, 每幾個禮拜就得重新解鎖帳號, 而且幾乎每次解鎖都要強迫我重設密碼, 然後我只要重設密碼, FB 的web hook API key就會失效, 就得重新產生一組新的API key用, 這真的只能說是他X的無奈...。不過因為我要的功能本來就是FB API現在不提供的, 所以我也只能自吃理虧吞下去了QQ
這段時間我也有試著調整登入的頻率tune看看能不能拉長ban帳號的時間, 不過基本上效果都不大, 感覺比較像是每次解鎖後信用值都reset, 然後每次用headless browser登入都會扣分, 當扣到一定程度的時候就又被鎖了, 這也讓我目前FB帳號的密碼快破40位數了XD
原本都只有上面被Ban帳號的問題, 不過沒想到今天發現FB機器人不會發文了, 查了一下發現用python登入FB後拿到的cookie變超少, csrf token則是拿不到, 要是沒有這兩樣, 那FB機器人就只剩下web hook回答問題的功能, 自動發文跟訂閱通知就都死掉了...。
再來只能思考解決方法了, cookie的話好處理, 我只要從原本的headless browser, 改成使用selenium真的去開個瀏覽器作登入就沒問題了。 而csrf token的話, 自己開監控封包看, 有一個非固定命名的js會去取得FB各種需要的變數:
恩..., 要從這裡下手應該不可能, 看那個命名就知道每次一定都長不一樣, 要解析FB的js邏輯才有辦法處理, 這樣要費的功夫太大, 所以完全不考慮。
如果沒辦法從取得變數的源頭取得, 那在來想到能作的就是直接從瀏覽器的監控封包取得csrf token, 稍微觀察了一下發現這個token雖然大多數都被使用在POST data裡, 可是還是有少部分是在GET request使用, 這樣我就直接看url就好, 比起看POST data會有效率的多!!
至於監控封包的方法, 最簡單的做法就是架個proxy去接selenium打出去的request, 然後再從proxy取資料出來, 就像下面stackoverflow的範例:
因為架個proxy去接我是當作下下策, 所以想說在找找看有沒有更好的方法, 然後發現其實有個近似的方案, 直接把selenium的log倒出來, 也能達到幾乎一樣的效果, selenium真是太神啦XD
簡單測試一下後, 我只要FB登入完稍微放著一下, FB自己前端的code打回server的GET request url就有幾個帶有csrf token了, 問題解決!!
幸好這次問題很快就解決, 不過現在回頭想想還是覺得很瞎, FB這次改版就只是把login.php改成登入後變成純跳板, 一樣都是要登入後才能拿到這些資訊, 這樣真的有變得比較安全嗎? 我怎麼感覺只是在搞人而已啊....。
麻... 問題有解決就好, 反正我想我也不會再寫下一個FB機器人了, 如果只要偶爾處理ban帳號的問題, 我是還維護得下去啦~~~。 希望未來不要繼續跟FB鬥法了XDD
