前端调试利器 Whistle安装使用

本文作者：牧毅，转自知乎，原文链接

背景

写代码是很舒服的一件事情，但是作为一个前端开发，通常还是会有很多的时间会去调试一些代码。

对于一些小型的项目，它们的环境很容易搭建，本地搭个环境跑起来，基本也就足够用了。然而，对于一些大型的项目，就没有那么方便了，基本别指望在本地能把整个项目跑起来。

这时候如果我们改了其中一个 js, 那么该怎么调试呢？

很容易能想到一个方法：我们要是把这个 js 的请求重定向到我们本地修改的那个就好了，这样我们就能直接在线上调试了，本地只要跑个构建脚本就行了。

没错！现在有不少工具可以来做这个事情：

Chrome DevTools 就可以做这个事情;
有不少插件可以更方便地做这个事情，如： Resource Override 插件和 ReRes 插件;
Windows 下还可以用 Fiddler — 良心之作，笔者之前一直都用这个，这么好用居然还是免费的！
MacOS 下不差钱的可以用 Charles.

最近呢，笔者换工作了，公司配的是 MBP, 这就尴尬了，没有 Fiddler 用了 o(╥﹏╥)o

插一句，有木有想换 MBP 的童鞋，欢迎来投简历：阿里南京 2019 秋招季/社招，诚邀加入~

Chrome DevTools 还是功能有点弱。Charles 是用不惯的。Resource Overrides 这种扩展虽好，但是它是通过 30X 重定向来搞的，所以呢 HTTPS 的资源重定向到 HTTP 的时候结果会报错……

Whistle 的功能和原理

终于，今天的主角 Whistle 登场了~

Whistle 的定位就是一个『跨平台web调试代理工具』，可以用来查看、修改HTTP、HTTPS、Websocket的请求、响应。

它的原理其实很简单，不是像 wireshark 一样直接在网卡上抓包，而是像 Fiddler 的代理模式 :

Whistle 自己会启动一个代理服务器;
我们自己需要配置下浏览器的代理走它的代理服务器;
然后 Whistle 就在代理的同时把 HTTP/HTTPS 的报文都给顺道截获了，当然像 Resource Override 一样顺手改改报文也不在话下了。

有人问 HTTPS 不是加密了吗？怎么也能截获？

这个问题问得好，原则上来说，HTTPS 的密文在代理服务器上是不能解密的；但是，有一种方法叫『中间人攻击』，通过这种方式，Whistle 就能将 HTTPS 的密文解密掉。

当然，这里澄清下，这种方式虽然是叫『中间人攻击』，但是也是要我们配合下 Whistle 才能行得通。Whistle 本身并不是恶意软件。

安装 Whistle

有木有想要迫不及待地想来试用下 Whistle 了呢？别着急，先安装下。

Whistle 是用 node.js 开发的，所以包是在 npm 上，可以用 npm 来安装：

> npm install -g whistle

当然，国内的话，建议使用淘宝的镜像：

> npm install whistle -g --registry=https://registry.npm.taobao.org

安装完后，会有两个可执行文件：whistle 和简写 w2.

可以看看其基本命令：

> w2 help

  Usage: w2 <command> [options]

  Commands:

    status              Show the running status of whistle
    use/add [filepath]  Set rules from a specified js file (.whistle.js by default)
    run                 Start a front service
    start               Start a background service
    stop                Stop current background service
    restart             Restart current background service
    help                Display help information

  Options:
  ...

启动 Whistle

启动命令如上面的 help 所展示的，有两个：

w2 run 是前台运行;
w2 start 是作为一个后台服务来运行。

比如说，我们先来前台运行吧：

这提示得相当详细了，我们就按照提示打开 http://127.0.0.1:8899/ 即可看到 Whistle 的操作界面。

不同于 Fiddler 和 Charles 这种原生的界面, Whistle 采用了 Web 页面的方式来做 UI, 这也是我喜欢它的原因之一，简洁，省了 UI 的开销。

配置 HTTPS

现在很多应用都 HTTPS 化了，如果要调试这些应用，免不了就要对 HTTPS 的资源进行处理。而在上面也提到了，Whistle 是利用『中间人攻击』的原理来抓 HTTPS 的报文的。所以呢，这里我们需要来信任下我们的中间人（Whistle）的根证书。

根证书在哪儿呢？在刚才打开的 http://127.0.0.1:8899/ 的页面顶部，有个 HTTPS 按钮，点一下，会出来弹出框。

弹出框如下图，点击 “Download RootCA” 即可下载。Whistle 还贴心地准备了一个二维码方便在手机上下载这个根证书。

然后，就是把这个证书设置成信任的就行了。

具体设置的方法，可以直接参考这个：安装跟证书

到这里安全意识强的童鞋脑子里忍不住有个问题：怎么可以就这么轻易地信任了这个根证书？

对于这个问题，其实主要在于两点：

这个根证书怎么来的？
谁能拿到这个根证书？

对于第一个问题，通过查看 Whistle 源代码，我们可以发现其实就是在 lib/https/ca.js 的 createRootCA() 函数中创建的。具体而言，是通过 node-forge 这个 HTTPS 的库创建的。

创建后根证书会默认存储到 ~/.WhistleAppData/.whistle/certs 目录下：

第二次启动 Whistle 的时候，根证书默认就取存储的根证书 — 当然，如果你觉得这个根证书不安全了（比如被泄露出去了），那你可以把这里的根证书删掉，Whistle 在启动的时候会自动再创建。

对于第二个问题，笔者目前没有发现 Whistle 有上传根证书的行为，但是，这个根证书默认的位置是固定的，所以所有有访问这个存储目录权限的用户/程序都可能拿到这个根证书。

安全提示：

建议启动 Whistle 时通过 -z 或 –certDir 参数来更换证书的存储目录，或者使用单独的账号来启动 Whistle ，并限制证书的存储目录的访问权限。

此外，建议定期更换证书 — 删掉这里的证书，然后重启 Whistle.

配置资源重载

打开 http://127.0.0.1:8899/#rules，首先来配置一条最简单的规则：

这代表把 https://example.com/ 的应答直接替换成 https://www.baidu.com/ 的。

点击【保存】来保存下这个配置，然后配置 Chrome （当然其他浏览器也一样）的代理是 127.0.0.1:8899

接着，用 Chrome 打开 https://example.com/，O(∩_∩)O哈哈，百度出现了~

同理，要替换 js 也是类似的操作。

比如一个常见的场景，线上 React 报错了 “Uncaught Error: Minified React error…”, 怎么办？这时我们可以把线上的这个 React 替换成 development 的同版本的 React:

https://xxx.com/js/react-v16.5.min.js https://unpkg.com/react@16.5.2/umd/react.development.js

这样，我们就能看到 React 具体报的啥错啦。

当然，Whistle 不光可以把 HTTPS 资源重载成另一个 HTTPS 资源，事实上 HTTP -> HTTPS, HTTPS -> HTTP 都是支持的。甚至本地文件也是支持的 — 使用 file:///path/to/your/file.js 即可。所有支持的替换方式可以参考下这里的协议列表: