首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【开发体验】前端调试必备-whistle 入门

【开发体验】前端调试必备-whistle 入门

作者头像
神仙朱
发布2021-08-13 14:19:06
2.4K0
发布2021-08-13 14:19:06
举报

小东西快快学快快记,大知识按计划学,不拖延

今天介绍一款前端必备的调试工具,真的真的非常好用,起码能提高几倍以上的调试效率。

想想一般我们开发项目的痛点

1.跨域问题。本地联调产生跨域,还得让后台接口origin设置个*,仍然存在一系列问题

2.难以模拟数据响应。后台接口没弄好,还要项目里面直接模拟数据

3.难以模拟请求多种情况。在不改动代码情况下,很难模拟请求的各种情况,加载超时,接口报错,接口各种状态响应,网络情况 等

4.请求重试成本高。出现问题的请求难以重试,难以保存证据。

5.手机调试比较麻烦

...等等的一系列问题,我以前都是这么过,很痛苦的,有了 whistle,真正解放我们的时间精力,让我们不再花时间在这些无谓的东西上。

whislte 功能很强大,本次只介绍下马上帮助到你的一些简单的配置,不难不会花你的太多时间。

如果你没用过,求求你学学吧。不要愿意以后麻烦很多,也不现在麻烦一点

好的,今天分3部分来说一下 whistle

1、基本原理

2、安装使用

3、基本使用

内容都很简单的

whistle 文档在此,http://wproxy.org/whistle/

另外,whistle 的作者在我们团队

基本原理

whistle 是一款 代理服务器,让所有请求都先经过 whistle,然后再转发到 真实服务器

所以我们可以在 whistle 拦截到请求的时候,对请求做很多定制化的操作,来模拟各种场景

就是这么简单,反正我们也没有涉及什么源码之类的,所以大概知道这其中的运行模式就可以了

怎么安装和使用安装方面的介绍,感觉没有必要放在本文描述,有点浪费篇幅,所以放在了另一篇

Whistle 安装

另外,whsitle 默认只能抓 http 的请求包,无法抓https ,如果要抓https,需要配置安装证书

Whistle 配置https 抓包

怎么使用

whistle 很强大,功能很多,我不会像翻译文档一样写,我会以自己最实际的体验来筛选出马上适用的点,并且进行分类

我会简单以这几个部分来详细说明,当你需要更加定制化请求的时候,你可以去看 whistle 的官网

1、项目开发的基本转变

2、常用的请求拦截修改

3、规则说明

4、其他高级修改

5、请求快捷操作

1

项目开发的基本转变

我们先去右键新建一个规则合集,尝试一下最简单的规则

添加一条规则

这个规则的意思就是访问 www.test.com 的时候,转成访问 127.0.0.1:5500 下的页面

原本本地开发的页面,我们只能访问127.0.0.1 或者 localhost,现在我们可以本地自定义域名访问了

这个带给我们最直接的便利就是

1、解决接口跨域,不求后台

本地开发调试接口的时候,难以避免会碰到跨域的问题,通常是接口加上跨域头*

其实根本没有必要,因为在生产环境 接口和页面的域名是一致的,根本不会出现这个问题

只是为了开发无奈加上,接口安全性就会降低一大截

2、解决跨域导致 Cookie 无用

我们通常使用 Cookie 来记录用户登陆状态,由后台写入返回,但是如果我们开发访问的是 localhost

Cookie 还有个毛用啊

3、开发时减少和生成环境的差异性

我们开发的时候,一定要尽量减少和生产环境的差异性,线上什么环境,本地尽量什么环境。

才会最大化减少我们线上遇到的问题。

我们肯定都遇到过,开发好好的,上线就一堆问题,根本原因就是没有在开发阶段充分模拟生产环境

1

项目开发的基本转变

上面已经使用 whistle 去解决本地开发调试了,下面我们将调试效率最高化

1简单数据mock

上面我们通过改变响应,让 test.com 的响应内容变成了 localhost 的响应

相应的我们同样可以改成接口的响应 ,来完成 mock。

添加一条规则

直接在whistle设置,让我们的接口直接返回我们写好的 json

这个json 在哪里?点击左侧菜单的 Values,然后右键 新建 json 文件,然后写入 json内容即可

访问我们的接口,就可以看到响应内容是我们写的json

接口mock 真是一个大痛了,完全没有一个便利低成本的方法,之前使用 easymock 或者项目里面加假数据,都十分之麻烦

2修改接口状态码

我们想对接口进行各种状态码的模拟是十分麻烦的,但是这种场景又是必须的,因为你要考虑到生产环境的多种情况

现在就方便多了

3接口延时

有时候我们需要处理接口超时,或者接口慢的情况,又是一个难处理的情况,现在不用担心了

来试下延迟3000ms

测试一下很准,从开始到响应花了 3011ms

4内容注入

哈哈,以前木马不是最喜欢玩的吗,给你的网页注入一些中奖弹窗现在我们同样可以修改请求,对请求内容进行各种注入

包括 html,js,css 等,对页面进行二次注入

比如给页面加一个小黑框

然后就像这样

再试试给页面js加个 alert

执行之后,就可以看到弹了个窗

上面都是在后面添加的,其实在 前面加,也可以直接替换整个文件内容

就像这样,prepend 表示在前面加,body 表示直接替换,append 表示在后面加

配置如下

比如我们开发的时候,通常会给界面注入一些环境变量

www.test.com localhost:5500 jsAppend://{test.js}

```test.js
 window.isTest=true
```

3

规则说明

上面我们简单写了一些规则,但是不一定明白这些规则是什么意思,下面就来说下

1规则释义

一个简单配置 test.com 转发到localhost的例子

光看名字可能不太好理解,意思就是

当有请求经过whistle,whistle 将请求url与pattern匹配,如果匹配到就执行operatorURI对应的操作,转发或者修改请求内容

2左边的 pattern 匹配模式

这个匹配模式 其实就是你制定怎么匹配你要的 请求url

匹配其实按程度分,就是 精确 和 模糊,你想精确匹配到某条请求,还是能同时匹配到多条请求的事 罢了

下面列举5种匹配写法,我给他们排了名,模糊级别

1、匹配域名(二级模糊

直接写一个完整的域

所有这个域名的请求,都转发到另一个域名,就是我们上面写的

www.test.com localhost:5500

它本身和下面的访问都会被一一转发,比如

www.test.com/xxx/xxx 都会 转发到 localhost/xxx/xxx

2、匹配路径(三级模糊

上面直接匹配域名,可能太模糊了,我想要对某个路径下的请求,做另一个处理

比如我们可以匹配接口转发到后台同学开发的某个ip端口

www.test.com/cgi-proxy localhost:7788

注意啊,这里如果你的 pattern 只有 路径是不行的啊,像这样

cgi-proxy localhost:7788

3、正则(可模糊,可精确,不参与排名

正则匹配是最正常的了,写法和 js 一样。一般我们也不太写正则

但是这里会有一个常用的写法就是,用来匹配路径

在上面的 【匹配路径】中,无法单独写一个路径进行匹配

但是!我们可以使用正则的方式实现,毕竟我不想写多一个域名啊

/cgi-proxy/ localhost:7788

这样就完成了url包含cgi-proxy的,都会被转发到localhost

如果是多个路径,使用 | 隔开

/cgi-proxy|cgi-node/ localhost:7788

4、精确(4级模糊

上面我们写的路径匹配,其实是会匹配到 子路径的

比如配置了这个

www.test.com/get_list file://{test.json}

固然 访问这个 get_list 可以返回 test.json

但是我们访问 get_list/xxx 同样可以..

我们要精准匹配到某条路径,只需要在 pattern 前面加一个 $ ,如下

$www.test.com/get_list   file://{test.json}

这样就行了

5、通配符(1级模糊

这个我愿称之为 最强模糊,但是同时它的规则也是比较繁杂的,不一一列举,就说一下常用的

通常写法有 一个 * 、两个*、三个*,他们表示的匹配模糊原则是不一样的 ,越多越模糊

其实通配符可以匹配 url 任意部分的复杂写法,但是我们暂时也没用到

了解更多内容,可以看

https://wproxy.org/whistle/pattern.html

3右边的 operatorURI 操作值

操作值可以有很多种写法

1、直接写在规则中

比如直接返回一个 json,懒得新建文件

www.test.com/get_list file://({msg:"dddd"})

记得要加上括号

2、放在 whistle 左侧菜单的 Values 或者 本地文件

values 就不说了,放个本地文件的例子

www.test.com/get_list file://C:\\Users\\Desktop\\test.json

window 才需要加 两个 /

3、内联在规则中

返回的内容有点多,但又不是很多多,不想新建文件和 写在 value,那么就直接内联在规则集吧

www.test.com/get_list file://{test.json}

```test.json

 {    
   msg:"1111"
 }
```

4operatorURI 之 协议

上面规则出现过 ,如 file,resDelay 这样的东西,它其实叫做协议。这个协议不是什么复杂的东西,它只不过是简化了修改操作而已。

一个单词就可以确定修改那部分内容

协议通常后面要加上 ://

5规则组合

在之前的规则中, pattern 和 operatorURI 好像都是一对一

如果是 一对多呢怎么办呢

一般原则是

1、合并。

相同 pattern 有 不相同的 operationURI 的

最终效果是合并,比如下面

接口先延迟3秒,然后返回success.json

在写法上,可以直接写成一条规则,顺序不定

2、靠前优先

相同 pattern 有相同的 operationURI ,谁在前面谁优先

比如这样,先配置了 success.json 的优先

那么接口只会返回success.json

还有像这种啊

你访问cgi-proxy 首先匹配到第一条规则,就会转发去了 localhost:5500/cgi-proxy

所以我们一般会把精确匹配的规则 放在前面,越模糊的规则越放后面

不然会导致请求匹配到 模糊的规则之后,就忽略了 后面精确的规则

注意!

上面说的是一般情况,其实还有更多情况,但是我觉得一开始大概了解就好了

1、不同operationURI 因为功能冲突无法合并。

2、相同协议 也能匹配合并。

4

其他规则

列举一些其他的规则协议,不常用,但是可以锦上添花

1过滤

过滤又分为 黑名单 和 白名单,这两个不仅可以单独过滤,还可以组合完成复杂的过滤

1.1 黑名单过滤

去掉匹配过滤规则的请求比如我们所有 cgi-proxy 的接口都转发到一个地方,除了 cgi-proxy/a

www.test.com/cgi-proxy file://{test.json} excludeFilter://*/cgi-proxy/a

上面过滤写的条件写的是 路径匹配过滤,我们也可以写成正则,全通配符等等

比如写成正则,排除路径中有 a 的请求

www.test.com/cgi-proxy file://{test.json}  excludeFilter:///a/

1.2 白名单过滤

只保留过滤规则的请求

www.test.com/cgi-proxy file://{test.json} includeFilter://*/cgi-proxy/a

只保留这条请求? 那我不如直接写成匹配这条请求算了,还整个过滤干嘛,可能只是功能有重叠而已吧

www.test.com/cgi-proxy/a file://{test.json}

2忽略

文档说的是 忽略协议

就是诸如 http,https,resDelay,file 这些

一般我们是本地开发 配置后台接口 转发的时候,会忽略某几条接口,让他们走去现网

比如 分享接口,获取用户信息接口 等

简单像这样,忽略全部协议

www.test.com/cgi-proxy/a ignore://*

或者只是忽略 https 的请求

www.test.com/cgi-proxy/a ignore://https

但是他也可以看做忽略所有规则

如果你只配置这样

www.test.com localhost:5500

www.test.com/aaa 会转发到 localhost:500/aaa

但是如果你写了

www.test.com/aaa ignore://*

那么是会直接忽略规则的,和 filter 有 异曲同工之处

如果你给接口配置了统一的规则,想去除某几条的话,会建议使用 ignore

3修改请求头或者响应内容

我们上面列举的都是修改请求头或者 响应内容的协议。

只是其中一小部分,还有很多内容

比如给请求头加上一个字段,比如我们加上一个origin 吧

www.test.com resCors://*

就可以看到这个请求被加上了

还有诸如什么 修改 cookie,referer 来规避CSRF 防御 都是可以的

5

请求快捷操作

在 Whistle 界面的 Network 会显示所有经过 whistle 转发的请求,这里主要讲几个功能

1、查看请求匹配的规则

我们给请求都配置了怎么多规则,怎么确定它到底匹配到哪个规则呢

可以看 whisle 界面 左侧 Network 菜单点击你的请求,可以在右边的面板中看到请求匹配的规则

如果匹配的规则没有成功,说明你的规则无效...

2、请求重发

我们一般抓到一个有问题的请求,怎么去复现它,是不是去看请求参数,请求头,然后自己postman重新构造一次,或者页面刷新?

哎呀,这样好麻烦啊,成本太高了

我们现在可以直接在whistle 对请求重试

右键请求,然后选择 Action -> Replay

然后就可以看到新增了一条请求

3、更改部分重发

如果我们需要修改部分参数,然后再重发呢?

右键请求,然后选择 Action -> Compose

或者,直接把请求拖到右边的 控制台

然后就能在 右边控制台看到对应的请求信息,就可以对请求 进行各种编辑了,然后再发送

yysy,真的对我们的调试开发帮助太大了,让我们拜托界面刷新的调试方式,解放精力做更多事情

最后

其实我也是一直用着 whistle,却没有非常系统地学习过,所以导致开发的时候,碰到也是懵逼懵逼

这次终于给总结完了

大家不会用的,赶紧用上了,不要因为懒就拖延了

现在麻烦一点,以后方便很多

鉴于本人能力有限,难免会有疏漏错误的地方,请大家多多包涵, 如果有任何描述不当的地方,欢迎后台联系本人,领取红包

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 神仙朱 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档