前端调试方法之偷天换日

发布于: 2020-08-20作者: 鱼肚最后更新: 2020-11-24

前端调试方法之偷天换日

本文中提出了一种调试前端应用的思路,适用于常见的SPA应用,已经在工作中使用了两个月且表现良好,供读者参考。

背景

一般来说,调试前端应用有两种套路:

  1. 在出现bug的场景中,打开devtools,跟踪source map调试问题
  2. 在本地启动前端应用,连接到对应的后端进行调试

这两种套路都有其局限性。

  1. 如果直接在浏览器中使用devtools进行调试,依赖于良好的source map,但是有时候出于安全或其它方面的考虑,某些环境(如生产环境)是不提供完备的source map的,调试起来非常困难。
  2. 如果本地启动前端应用,并连接到对应的后端。首先要处理好跨域问题、要处理好环境的切换。如果线上服务带有子路径,还需要处理路径不同等问题。总之在搭建环境的过程中,有可能遇到各种各样的困难。
  3. 有时候调试的网页不是自己控制的,没有源码,想基于线上的es5代码修改调试,上面的两种方法也很难做到。

思路

“偷天换日”调试法的核心思路,是通过本地篡改的方式,直接影响线上环境。

和后端应用不同,前端应用的所有代码,都是在浏览器中运行的。既然是在我们的主场,当然我们就可以对它进行一定程度的操控。

以前听过一个骗局,是讲有人通过展示自己的巨额比特币,获取别人的信任,而且主要受骗的是有一些技术水平的人。骗子通过录制视频的方式,展示自己在一个 通过HTTPS访问的,安全的比特币网站上,拥有巨量的比特币,尤其是其SSL证书的指纹和官方网站的指纹完全相同。最后揭秘骗子的手段就是通过浏览器插件篡改了网页的内容。

因此我想,如果能篡改SPA应用页面中的JS、CSS地址,改成本地地址,就能进行调试了。

原理

最开始尝试的方向是利用浏览器插件的Content Script,篡改HTML内容。这样当然是最暴力最简单的了,可惜不可行。

设想的流程是这样:

但是实际的流程是:

因为浏览器插件的Content Script是在HTML加载完毕之后才会加载的,在其有能力篡改之前,网页已经渲染出来了。即使此时再操作script标签换掉元素,之前的JS产生的一些全局变量等已经存在,较难清除。

后来搜索了很多,换了种实现方法,拦截指定网页的网络请求,做重定向。

拦截前的流程

拦截后的流程

在启用了如上图的拦截之后,就可以在本地启动 webpack-dev-server,或其它类型的server,也可以是另一个远程链接。使用本地的JS/CSS替代掉页面中原来的JS/CSS。

工具

搞明白原理之后,最开始我是打算自己写一个浏览器插件的。

然而秉承着“凡是我想到的,99%的已经被实现过”的原则,我搜索了下,然后发现了一个浏览器插件可以直接拿来使用。

插件地址: https://chrome.google.com/webstore/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii

代码地址:https://github.com/kylepaulsen/ResourceOverride

感兴趣的同学可以直接安装插件体验下,用法比较简单。如果没有科学上网打不开扩展商店的话,可以直接clone Github上的代码,然后打开开发者模式,加载本地插件。

安装好这个工具之后,在相应的规则配置页面,输入想要替换的URL地址,可使用 * 号通配符,再输入目标地址,即本地 webpack-dev-server 或其它服务产生的 JS/CSS地址即可完成替换。

替换完成之后,需要刷新页面生效。

在刷新之前,打开Chrome devtools,观察网络请求。如果Resource Override的规则配置正确的话,首先会看到原来的资源请求返回307的跳转状态码,Response Header中 Location 字段返回了新地址,即Resource Override中配置的目标地址。

之后,每次修改代码之后,触发webpack-dev-server重新构建,然后再重新载入页面即可。

HTTPS 的特殊处理

从原理上可知,浏览器插件做的只是资源请求的网络拦截,并做了次跳转。

所以在对待HTTPS的处理上,还是和原来的策略相同。

如果正在替换的网页是HTTPS的,而本地启动的 webpack-dev-server 默认是HTTP的,那就会触发浏览器的混合内容错误,即不允许在HTTPS的页面内加载HTTP的内容。

要解决这个问题主要有两种途径:

  1. 最简单的方式,是将本地路径的host换成 http://127.0.0.1,因为Chrome浏览器新版本中做了调整,对混合内容错误开了例外处理,来自 http://127.0.0.1的内容允许加载,而 http://localhosthttp://0.0.0.0 等方式访问时还是会触发错误。因此,我们只需要在Resource Override的目标地址中,写入 http://127.0.0.1 开头的地址即可,可以带端口号。这种方式依赖于浏览器的实现,在Chrome的旧版本,或其它浏览器上可能无法正常工作 。
  2. 另一种方式稍微复杂一些,是在本地启用HTTPS。如使用了webpack-dev-server,可配置其使用HTTPS证书。
1
2
3
4
5
6
7
8
9
module.exports = {
  //...
  devServer: {
    https: true,
    key: fs.readFileSync('/path/to/server.key'),
    cert: fs.readFileSync('/path/to/server.crt'),
    ca: fs.readFileSync('/path/to/ca.pem'),
  }
};

详细的HTTPS配置方式,可参阅 webpack 官方文档:https://webpack.js.org/configuration/dev-server/#devserverhttps

那么如何获取HTTPS证书呢?一般来说需要自己颁发证书,并在自己的电脑上安装和信任此证书或CA根证书。

关于自颁发证书,有兴趣的可参阅 mkcert 工具:https://github.com/FiloSottile/mkcert,如果不想这么麻烦,还是推荐使用方案1。

颁发证书之后,如果想设置给团队内其它人共同使用,可以参考我之前写过的一个脚本:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/usr/bin/env bash

# 本文件用于安装 https 证书,需要将证书文件改名为 ca.crt,并放置在此脚本同目录下
# 使用时需要提权,过程中会询问密码
# 依赖于 mkcert 命令,mkcert的安装方式参见: https://github.com/FiloSottile/mkcert
# Mac 上可使用 Homebrew 安装: brew install mkcert

# 如果安装 mkcert 工具遇到问题,也可以手动安装证书到系统中。双击 ca.crt 文件安装进系统,并打开钥匙串找到证书,点击信任并保存

# 如果是mac用户,自动使用brew安装mkcert
brewCmd=`command -v brew`
mkcertCmd=`command -v mkcert`
if [[ "x$mkcertCmd" == "x" ]]; then
  if [[ "$OSTYPE" == "darwin"* && "x$brewCmd" != "x" ]]; then
    brew install mkcert;
  fi;
fi;

mkcertCmd=`command -v mkcert`

if [[ "x$mkcertCmd" == "x" ]]; then
  echo "mkcert required, please install it first!  https://github.com/FiloSottile/mkcert";
  exit 1;
fi;

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
cp $DIR/ca.crt $DIR/rootCA.pem
CAROOT=$DIR mkcert -install

WebpackDllPlugin的特殊处理

如果使用了WebpackDllPlugin,则有可能会出现VendorLibrary is not defined的错误。

假设 webpack在 development模式 产生了 index.js 和 vendor.js 两个文件,在production模式生成 index.min.js 和 vendor.min.js。

注意这里 index.js / vendor.js 或 index.min.js / vendor.min.js 必须配套使用。

在Resource Override替换时,如果只替换了 index.min.js -> index.js,则会出现 index.js 和 vendor.min.js 配套使用的情况,DLL解析失败,导致出现VendorLibrary is not defined或其它奇奇怪怪的错。

解决办法有以下两种:

  1. 替换的时候,同时替换 index.js 和 vendor.js
  2. 本地 webpack-dev-server的时候,如果是用于篡改调试,可把 DllPlugin 配置改成production模式,加载mainfest.production.json

调试他人的代码

如果怀疑他人的代码有问题,但是没有源码可用来调试,也可以使用Resource Override做处理。

首先将对方应用中的JS文件下载下来,使用格式化工具将其格式化成基本可读的格式,本地将其调整之后,再通过本地服务(如 npm 的 serve 包,或nginx)提供此文件的本地地址,然后用 Resource Override工具,将原来的JS文件转换成本地修改过后的JS文件,即可实现调试他人的代码。虽然还是ES5代码比较难读,但至少可以通过修改文件、刷新页面的方式进行调试,可完成一些简单的任务。

常见的使用场景是跨部门协作或前后端协作时,找别人的BUG。

总结 & 使用心得

本文介绍了一种特殊的前端调试思路,及对应的方法和工具,可以在某些特殊的领域解决调试难的问题。

使用“偷天换日”调试法已经有将近两个月,也推广到了身边的同事使用,大家的反馈都是比较好用,感兴趣的读者可以尝试下。

关注我:
分享文章:

0条评论