Fiddler抓包調試前端腳本代碼


0、寫在前面的話

以前看了阮一峯老師關於互聯網協議入門的博客,受益不淺,接着再去體會了下HTTP協議,就想着看實際網絡訪問中的那些HTTP請求頭和響應是什麼樣的。Chrome的調試工具的Network選項其實已經夠用了,可是其格式爲了方便觀看作了調整,我想看原生的,就從網友處得知了比較專業的抓包工具:Fiddler。

基本使用仍是比較簡單的,能夠直接參考博客《 Fiddler 教程》。這裏想要吐槽的是,本人電腦的不知道什麼環境致使的Fiddler沒法抓取網頁的https請求,這個設置是能夠直接在軟件上打開的,然而個人電腦始終開啓後不生效,各類谷歌各類調鼓搗了超過4h仍然無果!如今那麼多網站都開始用https,不能抓取https的抓包工具豈不是逐漸成爲一隻鹹魚了。而我在同事一樣的win10 x64電腦同版本Fiddler設置抓取https,只按照普通設置花了大概3min不到就OK了,個人心態是崩潰的,謝謝。

另外,本文涉及的如何讓手機端也能在電腦上經過Fiddler抓包分析,請參考連接《 fiddler 手機 https 抓包》,主要參考文中的代理設置部分,若是不是抓取https,其餘的如證書安裝能夠略過。

一、背景介紹

以前看到一篇博客關於Fiddler的好處在於能夠在實際線上環境調整腳本代碼,即攔截腳本,本地修改後返回,在真實的環境下去調試,從而最大限度的減小bug發生的可能性。沒想到,昨天晚上就給我遇到了,老大問我公衆號的微信綁定爲何點擊肯定按鈕以後沒有反應,最終定位發現綁定在後臺是生效了,Ajax反饋前端的響應前端也收到了,問題在於回調函數。
$(function(){  
    //綁定
    $("#bound").click(function() {
        var username = $("#username").val();
        var password = $("#password").val();
        if(username.trim() == "" || password.trim() == "") {
            weui.topTips('用戶名或密碼不得爲空', 1500);
            return;
        }
        $().invoke("/weChat/grading/do/checkDepartment.q", {username:username, password:password}, function(re) {
            if(re == 'error') {
                weui.topTips('用戶名或密碼錯誤', 1500);
            } else {
                weui.confirm('綁定考級點:' + re,
                        //肯定
                        function() {
                            $().invoke("/weChat/grading/do/bound.q", {username:username, password:password}, function(re) {
                                if('success' == re) {
                                    weui.alert('綁定成功', function() {
                                        wx.closeWindow();
                                    });
                                } else {
                                    weui.alert(re);
                                }
                            });
                        },
                        //取消
                        function() {
                            //none
                        });
            }
        });
    });
});

二、方法1:Fiddler斷點抓包改響應

既然大概知道是回調函數出了問題,那麼先來判斷是回調函數沒有調用,仍是回調函數中的方法沒生效,仍是條件進入出現了問題。

Fiddler能夠在響應返回以前的「 請求以前」和「 請求以後」兩種狀態進行斷點,分別 能夠修改即將發送出去的請求和即將返回的響應,兩種方式在命令行的表示分別爲:
  • bpu
  • bpafter

咱們要改返回的腳本,因此也就是「請求以後」,則在命令行輸入 bpafter {url}:
 
在進入綁定頁面的時候,能夠看到已經對該部分進行了攔截:
 
咱們直接在響應中修改代碼,增長兩行alert用以斷定函數失效的位置,修改完成後,直接點擊Run to Completion便可:
 
結果兩個alert都觸發了,那麼問題出在哪呢,顯然就是weui.alert的問題了:

weui.alert方法是微信官方提供的js文件,並且我在本地運行,經過微信測試號進行測試時是ok的,客戶的公衆號正式上線以後,也測試是ok的,如今忽然莫名其妙就不生效了,你說氣不氣?關鍵是我再次用測試號進行測試,仍是有效的,就是在正式環境不行,我不懂,不知道是服務器環境問題,仍是正式公衆號和測試公衆號有什麼區別。因此這就是能在所謂真實線上環境調試才能儘量減小bug的緣由吧,謎,得燒香。 

接下來其實能夠繼續使用這個方法進行調試修改,爲了介紹另外一種方式,接下來的修改就採用自動攔截的方式,不過記得先清除以前的斷點攔截,輸入bpafter不帶url便可清除:
 

三、方法2:Fiddler自動攔截改響應

Fiddler能夠設置規則,自動對符合條件的url請求進行攔截,並返回指定的響應。這意味着咱們能夠把內容直接寫在本地的一個文件裏,自動攔截設置爲返回該文件,因此咱們每次調試代碼只須要修改本地文件便可,這樣一來:
  • 環境仍然是真實的服務器環境
  • 本地修改不會影響服務器的文件,也不會影響其餘人的請求
  • 本地能夠修改存儲,比斷點修改調試要方便不少

先把代碼寫在本地的一個txt文件中,由於是做爲響應返回,因此不能單純是文件內容,還應該加上響應頭,文件內容只是做爲響應內容體:
 
接下來設置自動攔截響應:
  • 找到AutoResponder頁面
  • 點擊Add Rule添加攔截規則
  • 編輯攔截規則,分別對應攔截的url和返回的響應內容
  • 選擇啓用規則Enable rules

好了,接下來咱們直接修改本地文件的內容。既然weui.alert在線上有問題,那麼咱們用它其餘的api,好比weui.toast:
 
保存好文件,再次訪問頁面,能夠看到fiddler的響應中,確實返回的是咱們本地文件的內容:
 
發現weui.toast在線上能夠正常運行:
 
那麼調試ok之後,直接把服務器上的內容按調試後的代碼進行修改從新部署,就好了。

fiddler的兩種方式修改響應,是否是很方便呢?
相關文章
相關標籤/搜索