2025-02-16 20:31:07
最近开发一个跨浏览器的扩展时,由于需要在 Content Script 中请求远端服务 API,在 Chrome 中没有遇到任何问题,但在 Firefox 中,它会在 Content Script 上应用网站的 CSP 规则。不幸的是,一些网站禁止在 Script 中请求它们不知道的 API 端点。
首先,这里出现了一个关键名词:CSP,又叫内容安全策略,主要是用来解决 XSS 的。基本上,它允许网站所有者通过服务端响应 Content-Security-Policy
Header 来控制网站页面可以请求的 API 端点。例如下面这个规则仅允许请求 https://onlinebanking.jumbobank.com,其他 API 端点的请求都将被浏览器拒绝。
1 |
|
也就是说,你可以打开 Twitter,并在网站 Devtools Console 中执行 fetch('https://placehold.co/200')
,然后就得到了一个 CSP 错误。
如果你将相同的代码放在扩展的 Content Script 中,然后在 Chrome 中测试扩展,一切正常。
而在 Firefox 中,嗯,你仍然会得到一个 CSP 错误。
如果你使用 Manifest V2,Firefox 则会正常放过,并且不会显示在 Network 中。吾辈甚至不想知道它做了什么。
经过一番调查,吾辈成功找到了相关的 issue,而它们均创建于 9 年前,最新的讨论甚至在 4 天前。检查下面两个 issue。
那么,问题就在这儿,看起来也无法在短期内解决,如果想要让自己的扩展支持 Firefox,现在应该怎么办?
好吧,基本思路有 2 个:
declarativeNetRequest/webRequestBlocking
API 来修改或删除它们呢?首先需要在 Background Script 中定义接口,准备接受参数并转发请求。
1 |
|
同时必须在 manifest 中 声明正确的 host_permissions
权限,添加你要请求的域名。
1 |
|
然后在 Content Script 中调用它。
1 |
|
可以看到现在可以正常得到结果了,但这种方式的主要问题是与原始的 fetch 接口并不相同,上面实现了 blob 类型的请求接口,但并未完整支持 fetch 的所有功能。嗯,考虑到 Request/Response 都不是完全可以序列化的,这会有点麻烦。
接下来,将介绍一种非侵入式的方法,允许在不修改 Content Script 解决该问题,首先是 declarativeNetRequest API,由于 WebRequestBlocking API 被广泛的应用于广告拦截器中,直接导致了 Chrome Manifest V3 正式将其废弃,并推出了静态的 declarativeNetRequest API 替代(尽管远远不能完全替代),但对于解决当下的这个问题很有用,而且很简单。
首先在 manifest 中声明权限,注意 host_permissions 需要包含你要处理的网站。
1 |
|
然后在 public 目录中添加一个 rules.json 文件,其中定义了要删除 x.com 上的 content-security-policy
response header。
1 |
|
可以看到网站的 CSP 已经不复存在,可以看到浏览器也不会拦截你的请求了。但是,这种方法的主要问题是网站安全性受损,就这点而言,这不是一个好方法。
一般而言,推荐使用 Background Script 转发请求,尽管它要编写更多的样板代码,吾辈也就此在 WXT 上问过框架作者,他似乎一般也会这样做。
参考: https://github.com/wxt-dev/wxt/discussions/1442#discussioncomment-12219769
2025-01-30 09:21:28
最近在实现 Mass Block Twitter 插件的 Spam 账户共享黑名单时,使用了 Cloudflare D1 作为服务端的存储数据库。而之前在本地 indexedDB 中已经存储了一些数据,所以需要导入现有的数据到 Cloudflare D1 中。使用 IndexedDB Exporter 插件将 indexedDB 数据库导出为 JSON 数据,但如何导入仍然是个问题。
最初参考了 Cloudfalre D1 的官方文档,但它并没有如何导入 JSON 数据的指南,而且它也只能在 Cloudflare Worker 中使用,但它确实提供通过 wrangler 执行 SQL 的功能,所以重要的是如何从 JSON 得到 SQL。
最初看起来这很简单,既然已经有了 JSON 数据,从 JSON 数据生成 SQL 字符串似乎并不难,只需要一些简单的字符串拼接即可。但实际上比想象中的麻烦,主要是 SQL 中有许多转义很烦人,边界情况似乎很多,JSON.stringify 生成的字符串在 SQL 中有错误的语法。
例如
"
双引号'
单引号\n
换行虽然也调研过一些现有的 npm 包,例如 json-sql-builder2,但它似乎并不支持生成在单个 SQL 中插入多行的功能,因此一开始并为考虑。而且它生成的结果如下,看起来是给代码用的,而非直接可以执行的 SQL 文件。
1
2
3
4
{
"sql": "INSERT INTO people (first_name, last_name, age) VALUES (?, ?, ?)",
"values": ["John", "Doe", 40]
}
在生成的 SQL 一直出现语法错误之后,一度尝试过直接在 Worker 中实现一个 API 用来做这件事,直到在 wrangler dev 在本地测试发现效率很低后放弃了,实现 API 本身反而并不复杂。
最后还是回归到生成 SQL 的方案上,基本流程如下
1 |
|
1 |
|
Cloudflare D1 是一个不错的数据库,基本在 Web 场景中是完全可用的,而且与 Worker 一起使用时也无需关注 Worker 执行的区域与数据库所在的区域可能不一致的问题。而关于这次的数据导入的麻烦,如果已经熟悉 D1 或数据库的话,可能 10 分钟就搞定了,还是太久不碰数据库和后端生疏了。
2025-01-02 22:58:59
在实现 Chrome 插件 Mass Block Twitter 时,需要批量屏蔽 twitter spam 用户,而 twitter 的请求 header 包含的 auth 信息似乎是通过 js 动态生成的,所以考虑到与其检查 twitter 的 auth 信息是如何生成的,还不如拦截现有的网络请求,记录使用的所有 header,然后在调用 /i/api/1.1/blocks/create.json
接口时直接使用现成的 headers。因而出现了拦截 xhr 的需求,之前也遇到过需要拦截 fetch 请求的情况,而目前现有的库并不能满足需要。
已经调查的库包括
因此,吾辈打算自己实现一个。
首先,吾辈思考了自己的需求
确定了需求之后吾辈开始尝试设计 API,由于之前使用过非常优秀的 Web 框架 hono,所以吾辈希望 API 能够尽可能的简单,就像 hono 的 Middleware 那样。
下面借用 hono 官方的 Middleware 的洋葱图 [1]
例如下面使用了两个 Middleware
1 |
|
实际运行结果将会如下,因为最早注册的 Middleware 将在“洋葱”的最外层,在请求处理开始时最先执行,在请求完成后最后执行。
1 |
|
接下来就涉及到具体实现 fetch/xhr 的请求拦截了,这里不会给出完整的实现代码,而是更多给出实现思路,最后将会链接到实际的 GitHub 仓库。
首先说 fetch,它的拦截还是比较简单的,因为 fetch 本身只涉及到一个函数,而且输入与输出比较简单。
先看一个简单的 fetch 使用示例
1 |
|
基本思路就是重写 globalThis.fetch
,然后使用自定的实现运行 middlewares,并在合适的时机调用原始的 fetch。
1 |
|
现在,可以简单的拦截所有的 fetch 请求了。
1 |
|
有人可能会有疑问,这与 hono 的 Middleware API 也不一样啊?别着急,API 在最外层包一下就好了,先实现关键的请求拦截部分。
接下来是 xhr,它与 fetch 非常不同,先看一个简单的 xhr 使用示例
1 |
|
可以看出,xhr 涉及到多个方法,例如 open/onload/send
等等,所以需要重写多个方法。而且由于 middlewares 只应该运行一次,而 xhr 的 method/url 与 body 是分步传递的,所以在实际调用 send 之前,都不能调用原始 xhr 的方法。
1 |
|
现在实现了一个非常基本的 xhr 拦截器,可以记录和修改 request 的 method/url/body,还能记录 response 的 status/body。
1 |
|
当然,目前 xhr 的实现还非常简陋,没有记录所有 onload/onerror/onreadystatechange 事件,也没有记录所有 header,更不能修改 response。但作为一个演示,整体的实现思路已经出来了。
目前已经实现了完整的 fetch/xhr 拦截器,发布至 npm 上的 @rxliuli/vista 包中,欢迎使用。
2025-01-02 22:54:49
自从 2023 年底前往日本之后,吾辈就没有再上过一天班。在日本的时候,基本没有考虑过打零工。而回国之后,则开始了间隔性的旅行和躺平。回国的主要目标之一成为独立开发者仍未实现,即使尝试过开发一些东西,但都没有找到正确的途径。而且严重缺乏输入,现实几乎没有人可以长期交流,这是一个问题,可能一直都是一个问题。
1~3 月: 在日本留学,在关西地区旅行,也前往东京进行过短期旅行
4~6 月: 完成了全国旅行,虽然途径磕磕绊绊,但最终吾辈还是做到了
7 月: 在阳江租房长住,但实际上几乎没有出门玩过,月底回到老家两周
8 月: 在阳江躺平,月底终于前往了当地的海陵岛,(服务)体验一般
9 月: 月初终于继续旅行,历经衡山长沙南京镇江之后,遇到台风匆匆赶回
10 月: 前往新一家暂住一周多,之后前往云南昆明大理等地,10 月下旬返回
11~12 月: 完全在阳江躺平,并陷入了严重失调的日常生活
2024 年,主要还是开发了各种各样的 Chrome 插件,目前还在维护的大概有十几个,但大多数都反响平平,而且始终没有考虑过盈利问题,也许是因为毕竟没有盈利的压力。其中花费了大量时间开发的 PhotoShare 和 NovaChat,则没有真正完成和推广过。也许随着旅程的继续,吾辈将寻找到真正通往胜利的道路。
下面是 2024 维护过的东西
Worm 是一部网络小说,也是自魔法少女小圆之后又一部真正热爱的作品。同样是从同人小说开始入坑,看完可能上百本同人小说,仅浏览记录就有 4257 个,而相同时间内 Twitter 浏览记录仅有 205 个,这确实说明了吾辈花费了多少时间。小说中的泰勒面对了各种困境和挑战,不得不因正确的理由做错事,从一个备受欺凌、想成为超级英雄的女高中生,到成为接管城市的超级反派,最终拯救了世界却被人害怕而招致死亡。至少可以说,“升级女王”是一个让人尊敬的女孩,上一个让吾辈有这种感觉的还是一之濑琴美,以及更早的樱小路露娜,她们都曾经历了痛苦但都成功地克服了它们,或许这正是吾辈喜欢她们的理由。
下面是作品简介:
主角是一个名叫泰勒・赫伯特的女高中生,是个失去母亲的黑发褐肤、性格阴郁的女孩。她在学校遭受霸凌,唯一支撑她活下去的希望是:不久前她经历了 “触发事件”,获得了控制昆虫的超能力。如果她能顺利参加“监护者计划”,就能成为一个真正的超级英雄,为她那悲惨的人生增添一些意义…
推荐从 TV Tropes 寻找喜欢的 Worm 同人小说,就英文圈子而言,它大概有 15k 本同人小说,是 Madoka 英文同人圈的 3~4 倍。
2025 年吾辈仍然不会考虑长期工作,目前仍然有时间和成本去尝试做一些不一样的事情,如果八爷独立开发之路步入正轨花了 3 年,那么吾辈也可以花费同样多的时间。下面立一些 2025 的 Flag,将每个月都 check 一下
2024-11-13 02:52:02
最近使用了 ZenFS 在浏览器中模拟文件系统,以在浏览器中像使用 node fs api 一样存储一些文件。但想要可视化的检查当前存储的文件时,却没有一个可以直观的工具来完成。所以就创建了一个 Chrome Devtools Extension ZenFS Viewer,以实现这个目标。在此过程中就遇到了如何传递 ArrayBuffer 从网页到 devtools panel 线程的问题,一些尝试如下。
首先尝试了最简单的方法,browser.devtools.inspectedWindow.eval
可以在网页执行任意代码并得到结果,例如
1 |
|
然而 inspectedWindow.eval 并不支持 Promise 返回值,例如下面的表达式无法得到 Promise 结果
1 |
|
同样的,也无法支持 ArrayBuffer。所以这个显而易见的 API 被放弃了。
1 |
|
接下来就是思想体操的时候了,一开始考虑的方案就是通过 devtools panel => background script => content-script(isolation) => content-script(main) 进行中转通信,以此在 devtools panel 中调用网页的全局变量并传递和获取 ArrayBuffer 的响应。大概示意图如下
然而在使用 chrome.runtime.sendMessage
时也遇到了和 inspectedWindow.eval
类似的问题,无法传递 ArrayBuffer,仅支持 JSON Value。当然可以序列化 ArrayBuffer 为 JSON,但在传输视频之类的大型数据时并不现实。
之后经过一些搜索和思考,找到了一种方法可以绕道 chrome.runtime.message,因为注入的 iframe 和 devtools panel 同源,所以可以使用 BroadcastChannel 通信,而 iframe 和注入的 content-script(main world) 之间尽管不同源,但仍然可以通过 postMessage/onMessage 来通信,并且两者都支持传递 ArrayBuffer,这样便可绕道成功。
网页与注入的 iframe 之间,通信可以使用基本的 postMessage/onMessage 实现,为了减少冗余代码,这里使用 comlink 来实现。
先看看注入的 content-script,它主要是负责对 iframe 暴露一些 API 的。
1 |
|
而在 iframe 中,则需要转发所有来自 BroadcastChannel 的请求通过 postMessage 传递到上层注入的 content-script 中,其中在每次传递 ArrayBuffer 时都需要使用 transfer 来转移对象到不同线程。
1 |
|
而在 Devtools 中,要做的事情有一点点多 🤏。首先需要注入两个 content-script,而其中 isolation-content.js 是用来创建 iframe 的 content-script。
1 |
|
1 |
|
接下来就可以在 devtools-panel 中获取数据了,由于 iframe 的注入完成的时机并不能确定,所以需要加个简单的通知机制。
1 |
|
1 |
|
完整代码参考: https://github.com/rxliuli/devtools-webpage-message-demo
至今为止,仍然没有简单的方法来支持 Devtools Extension 与 Webpage 之间的通信来替代 inspectedWindow.eval
,确实是有点神奇。