使用 Greasemonkey 或用户脚本将远程 JavaScript 文件替换为本地调试副本
在调试使用 Google 后端的客户端应用程序时，我添加了一些函数的调试版本，并使用 Chrome 开发人员工具脚本编辑器插入它们。
然而这种方法有很多限制，首先是编辑器似乎并不总是可以处理压缩文件，并且当 JS 文件长为 35K 行时，这是一个问题。
另一个问题是，在加载期间完成的所有初始化都使用原始的“未修补”函数，因此这并不理想。
我想用我自己的本地副本替换远程 javascript.js 文件，大概在文件名上使用一些正则表达式，或者任何合适的策略，我很乐意使用 Firefox 或 Chrome，如果一个比另一个容易。
While debugging a client app that uses a Google backend, I have added some debugging versions of the functions and inserted them using the Chrome Developer Tools script editor.
However there are a number of limitations with this approach, first is that the editor doesn't seem to always work with de-minified files, and when the JS file is 35K lines long, this is a problem.
Another issue is that all the initialization that is done during load time, uses the original "unpatched" functions, hence this is not ideal.
I would like to replace the remote javascript.js file with my own local copy, presumably using some regex on the file name, or whatever strategy was suitable, I am happy to use either Firefox or Chrome, if one was easier than the other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，基本上，正如@BrockAdams 所指出的，根据需求，这些类型的问题有几种解决方案，并且它们遵循两种方法中的一种。
浏览器 API 切换。
firefox 和 chrome 都支持浏览器扩展，这些扩展可以利用平台特定的 API 分别为 firefox 和 chrome 的“onbeforeload”或“onBeforeRequest”注册事件处理程序。 Chrome API 目前处于实验阶段，因此这些工具在 Firefox 下可能会得到更好的开发。
绝对可以完成所需任务的 2 个工具是 AdBlock plus 和 Jsdeminifier 两者都有可用的源代码。
这两个 Firefox 应用程序的关键点在于，它们在浏览器获取 Web 请求之前拦截该请求，并在 http/https 加密阶段的另一端进行操作，因此可以看到解密的响应，但是正如另一篇文章中指出的那样，他们没有t完成整个事情，虽然 jsdeminifier 非常有用，但我没有找到一个 firefox 插件来完全完成我想要的事情，但我可以从以前的插件中看到，firefox 和 chrome 都可以。尽管他们实际上并没有按照要求完成任务。
基于代理的拦截迷惑 这绝对是普通 HTTP 环境中更好的选择，有很多代理，例如 pivoxy、fiddler2、Charles Web HTTP 代理，大概还有一些我没有专门研究过的东西，比如支持某种过滤的 snort。
对我自己来说，最简单的解决方案是 firefox 上的 Foxyproxy 和 privoxy，并配置 user.action 和 user.filter 来检测页面的 url，然后应用一个过滤器，将原始 src 标签替换为我自己的过滤器。
https 案例。代理与插件
当请求是 https 时，代理无法看到请求 url 或响应正文，因此它无法执行很酷的交换操作。不过，对于那些喜欢摆弄浏览器的人来说，有一种选择。这就是中间人 SSL 代理。 Charles Web HTTP 代理 似乎是此问题的主要解决方案。基本上它的工作方式是，当您的浏览器向远程 HTTPS 服务器发出请求时，ssl 代理会拦截该请求，并根据服务器的 IP 地址动态生成一个服务器证书，并使用自己的根 CA 对该证书进行签名，并发送回浏览器。浏览器显然会抱怨自签名证书，但在这里您可以选择将 ssl 代理根 CA 证书安装到浏览器中，这会迷惑浏览器并允许 ssl 代理介入中间并对原始响应进行替换和过滤身体。
或者推出您自己的 Chrome 扩展
我决定推出我自己的 chrome 扩展程序，我计划将其提供给大家。目前它处于非常硬编码的状态，符合我自己的需求状态，但它工作得很好，即使对于 https 请求也是如此，另一个好处是浏览器插件解决方案可以与浏览器开发人员工具更紧密地集成。
So basically, as @BrockAdams identified, there are a couple of solutions to these types of problem depending on the requirements, and they follow either 1 of 2 methods.
the browser API switcharoo.
Both firefox and chrome support browser extensions that can take advantage of platform specific APIs to register event handlers for "onbeforeload" or "onBeforeRequest" in the case of firefox and chrome respectively. The chrome APIs are currently experimental, hence these tools are likely to be better developed under firefox.
2 tools that definitely do something like what is required are AdBlock plus and Jsdeminifier both of which have the source code available.
The key point for these 2 firefox apps is that they intercept the web request before the browser gets its hands on it and operate on the other side of the http/https encrpytion stage, hence can see the decrypted response, however as identified in the other post that they don't do the whole thing, although the jsdeminifier was very useful, I didn't find a firefox plugin to do exactly what I wanted, but I can see from those previous plugins, that it is possible with both firefox and chrome. Though they don't actually do the trick as required.
The proxy based interception befiddlement This is definitely the better option in a plain HTTP environment, there are whole bunch of proxies such as pivoxy, fiddler2, Charles Web HTTP proxy, and presumably some that I didn't look at specifically such as snort that support filtering of some sort.
The simplest solution for myself was foxyproxy and privoxy on firefox, and configure a user.action and user.filter to detect the url of the page, and then to apply a filter which swapped out the original src tag, for my own one.
The https case. proxy vs plugin
When the request is https the proxy can't see the request url or the response body, so it can't do the cool swapping stuff. However there is one option available for those who like to mess with their browser. And that is the man-in-the-middle SSL proxy. The Charles Web HTTP proxy appears to be the main solution to this problem. Basically the way it works is that when your browser makes a request to the remote HTTPS server, the ssl proxy intercepts the request and from the ip address of the server generates a server certificate on the fly, which it signs with its own root CA, and sends back to the browser. The browser obviously complains about the self-signed cert, but here you can choose to install the ssl proxy root CA cert into the browser, befuddling the browser and allowing the ssl proxy to man in the middle and make replacements and filters on the raw response body.
Alternative roll your own chrome extension
I decided to go with rolling my own chrome extension, which I am planning to make available. Currently its in a very hardcoded to my own requirements state, but it works pretty good, even for https requests and another benefit is that a browser plugin solution can be more tightly integrated with the browser developer tools.