美文网首页
Fiddler实践心得

Fiddler实践心得

作者: 夜境 | 来源:发表于2017-09-13 10:34 被阅读133次

    本文章转载于搜狗测试

    一、打断点和AutoResponder返回404/502等状态码的不同

    之前一直以为这两种方式没有区别,都是阻断了请求,改变了返回结果。但是今天在测一个问题时,恍然间明白了两者的不同。

    1、打断点,是阻塞了请求,一直没有结果返回,请求将在线程中一直存在,直到超时被踢出来。

    2、AutoResponder返回404/502,这种情况是有结果返回的,代表请求也结束了,不会在线程中一直存在。

    线程,细心的朋友可能发现了,线程,是的,在遇到线程相关的问题时,两者就明显的不同了。

    其实在发现两者在线程上的不同之后,再仔细思考这个问题,两者本质上是服务器是否响应的问题,是否有状态码的问题。打断点阻塞,没有状态码,服务器是没有响应。404/502是服务器有响应的。体现中线程中的不同,只是一个症状体现而已。

    二、修改Response数据时要注意超时的问题

    通过设置Rules -> Automatic Breakpoints ->After Response,之后再修改响应回来的数据,来实现修改response的内容。但是这样修改数据很容易造成另外一个问题,那就是请求超时导致客户端不对请求做处理。

    怎么理解呢? 就是客户端发送一个请求出去,如果在指定的时间内请求没有返回,则认为该请求超时了,就算以后这个请求返回数据,则客户端也不再对请求做出响应。

    如果,修改内容的操作能够很快的进行,放行断点,在超时时间之内完成,那么修改之后的内容将会被客户端处理。

    如果,修改内容的操作大于超时时间,就算之后将断点放行,请求返回200,这个时候客户端是不做任何处理的,也可以理解为修改的内容没有产生效果。

    综合上述,一定要注意修改内容的操作时间和超时时间的关系。

    其实在修改数据的时候,不太容易去把控时间的长短,也很容易造成修改数据失误,那么怎么样才能很好的解决这个问题呢?

    可以用AutoResponder自动响应数据,用本地文件替换服务器的返回数据。这样就不用在打断点之后急忙的修改数据,也不怕一不小心把数据修改错了。AutoResponder功能替换是一瞬间的事儿,也不用担心超时的问题,真的是一举两得啊。

    三、重新认识Decode

    在之前的认识中,知道有这样的Decode在工具栏中,也知道是解密的,但是在实践中并没有涉及到这块,今天就被我碰到了,而且自己也跳到坑里了,还好还好最后终于明白了。

    Decode在平时默认是被选中的,我不知道什么时候就给取消了。

    今天的情况是这个样子的:

    客户端请求一个接口的数据是加密的,通过save -> response -> response body ,将返回结果保存下来,之后用这个本地文件替换服务器返回的数据。结果客户端接到数据之后,在后台报了一个错误,提示数据格式不对。

    正常的业务流程是客户端在接到数据之后,需要对数据进行解密。现在是在对数据解密的时候发现数据格式不对。

    保存下来的response body,如下所示:

    服务端一阵排查问题,客户端一阵排查问题,没毛病啊!!!最后问我,你的本地文件内容是什么?我把内容贴出去之后,大家都是很疑问 6 、0 是怎么回事?

    服务端说不是我们返回的,客户端说不是我们添加的。

    OH MY GOD ! 我也急了,怎么可能是我这里的问题,平时都是这样用本地文件替换服务器文件的,没毛病啊!

    后来仔细瞅了瞅,发现了 Response body is encoded ,Click to decode . 点了一下,哦~~~顿时豁然开朗。

    第一行和最后一行是数字,其实是对数据failed加的密,虽然看起来是明文,6是数据failed的长度。

    应该也看到Response body is encoded. Click to decode. understand ? 点击一下就可以解密了。

    解密之后的数据,如下所示:

    这个时候再save -> response -> response body ,将返回结果保存下来,AutoResponder替换服务器文件,客户端就可以正常的解密运行了。

    问题虽然是解决了,但是得找到真正的原因啊?

    提到解密,当然是第一时间想到了Decode,一看,居然没有被选中,突然间就明白了Decode的作用,如果返回的数据时加密的,就自动解密。

    为了验证,选中Decode,又重新请求了一次,结果你猜怎么着,还真的是这个道理。

    细节决定成败啊,任何一个小功能都不能被忽视啊!盆友们啊,都要慎重啊,慎重!

    四、bpu 阻塞多个请求

    背景:

    今天同事问我,bpu怎么同时阻塞多个请求呢?

    同事 :

    我是这样写的 bpu a b ,我这样写怎么实现不了同时阻塞a 和 b 请求呢?

    我:

    我没有这样阻塞过,但是在我的理解里应该这样写,bpu a enter执行,bpu b enter执行,分开执行(因为我之前没有这样阻塞过,只是按照自己的理解这样认为的,接下来就打脸了,不都是你以为的就是你以为的啊,泪奔啊)。

    同事:

    我按照你说的方式做了,但是还是不可以啊。

    额~,好尴尬啊

    我只有默默的打开Fiddler,ctr+R打开脚本,ctr+F 输入关键字 bpu,找到bpu命令所在的核心代码

    case "bpu":

    var len = sParams.Length ;

    if(sParams.Length<2){

    bpRequestURI=null; FiddlerObject.StatusText="bpRequestURI breakpoint cleared";

    return false;

    }

    var len = sParams.Length ;

    bpRequestURI= sParams[1];

    FiddlerObject.StatusText="RequestURI breakpoint for "+sParams[1];

    return true;

    核心: bpRequestURI= sParams[1]; 只取了一个参数值。

    场景1解析(也就是同事的执行方法): bpu /sdk /zwf ,

    使用空格隔开的,那么

    sParams[0] = “bpu”

    sParams[1] = “/sdk”

    sParams[2] = “/zwf”

    只取了sParams[1] = “/sdk”,所以只会阻塞包含/sdk的请求

    场景2解析(也就是我认为的方法,允许我哭一会):

    bpu /sdk

    bpu /zwf

    每次执行bpRequestURI,都会被赋新值,所以我阻塞包含/zwf 的请求

    我们怎么样才可以实现,阻塞多个请求呢?

    让我沿着核心代码,顺藤抹瓜,ctr+F 输入关键字 bpRequestURI 查询,找到参数定义的地方

    这个是定义变量的地方,是全局变量

    //在main()方法中

    // These static variables are used for simple breakpointing & other QuickExec rules

    BindPref("fiddlerscript.ephemeral.bpRequestURI")

    publicstaticvarbpRequestURI:String=null;

    找到使用此参数,bpRequestURI 不为null,并且 请求的uri 包含bpRequestURI ,则阻断该请求

    if((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) {

    oSession["x-breakrequest"]="uri";

    }

    这样捋下来,就搞明白了,阻塞请求是怎么个原理了,是不是也很简单呢?!

    接下来就是改造它来实现bpu 阻塞多个请求了。

    第一步:

    //在main()添加如下代码

    BindPref(“fiddlerscript.ephemeral.bpRequestURI”)

    //数组的长度10,10个阻塞的命令,内容为空格,和bpu命令用空格分割保持一致

    public static var bpRequestURIs:String[] = [” “,” “,” “,” “,” “,” “,” “,” “,” “,” “] ;

    第二步:

    case"bpu":

    varlen1 = sParams.Length ;

    varlen2 = bpRequestURIs.Length;

    //每次赋值之前先恢复原始值

    for(vari =0; i< len2; i++){

    bpRequestURIs[i]=" ";

    }

    if(len1 <2) {bpRequestURI=null; FiddlerObject.StatusText="RequestURI breakpoint cleared";returnfalse;}

    vartext ="";

    for(vari =1; i < len1; i++){

    bpRequestURIs[i-1] = sParams[i];

    text += sParams[i] +" ";

    }

    FiddlerObject.StatusText="RequestURI breakpoint for "+ text;

    returntrue;

    第三步:

    // 在OnBeforeRequest() 方法中

    // 注释掉之前的方法

    //  if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) {

    //      oSession["x-breakrequest"]="uri";

    //  }

    varlen= bpRequestURIs.Length;

    for(vari =0; i

    if(bpRequestURIs[i]!=null && bpRequestURIs[i]!=" "&& oSession.uriContains(bpRequestURIs[i]) ){

    oSession["x-breakrequest"]="uri";

    }

    }

    完成,这样就完成了bpu同时阻塞多个请求了!

    相关文章

      网友评论

          本文标题:Fiddler实践心得

          本文链接:https://www.haomeiwen.com/subject/tzjksxtx.html