jsproxy

迫于公司的网络政策严格, 域名黑白名单和GFW同时运作, 且封锁了我力所能及的全部代理渠道, 所以刚入职时被锁在墙内的我, 在面向搜索引擎编程的时候, 看着百度出来满屏互相复制粘贴的CSDN, 感到了十分的...不适.

后来用了必应国际版以及不知道为啥没有被锁的鸭鸭走(duckduckgo), 虽然比百度好了几条街, 但还是没有Google来的习惯. 所以又开始以各种体位探索爬墙...

这个时候就要介绍一下jsproxy这个项目了, 这是一个基于浏览器端JS实现的在线代理. 相比传统的在线代理, jsproxy并不需要服务端做过多的分析和处理, 只需要简单地转发流量, 其他的工作交给了浏览器端进行. 浏览器的Service Worker能拦截网页的请求, 并自定义返回内容, 相当于在浏览器内部实现一个反向代理, 实现方式非常巧妙. 赞美EtherDream大佬的作品!

当然对于我来说, 最重要的是, 只要能在一个按公司规定可以访问的域名下搭建好jsproxy, 我就可以重返Google的怀抱了. 由于项目前端是静态网页和JS, 可以托管在Github Pages上, 而github.io域名是公司可以访问的, 完美~

项目提供了一键部署的脚本, 可以很方便地部署在云服务器上. 正常来说脚本跑完, 返回的xxx.xxx.xxx.xxx.nip.io:8443 这个域名就可以正常访问使用了, 但是我还是选择继续托管在Github Pages上. 它还支持CloudFlare Workers实现方式, 按请求次数计费, 免费套餐就够用! 我就不赘述了, 具体部署细节可以点云主机一键部署脚本和使用CloudFlare Workers免费部署.

作者提供的Demo页面:

https://zjcqoo.github.io/

我自己搭的:

https://js.jimmytinsley.workers.dev/
https://jimmytinsley.github.io/

jsproxy-firefox-extension

虽然在代理功能方面, jsproxy已经能完全满足我的需求, 但是在易用性上还是稍微有点不够. 如果我需要使用代理打开某一个网页, 需要先复制这个网页的url, 然后打开jsproxy的Page Sandbox页面, 粘贴进地址栏, 选定节点, 再点击Go按钮才能打开这个网页, 步骤略微有点多. 尽管可以通过保存常用地址到书签来快速访问, 但这显然不是最好的解决办法.

使用jsproxy代理访问网页只需要在前面加上一个类似https://jsproxy.gq/-----的前缀, 这个前缀是自己搭建的jsproxy前端Page Sandbox url再加上五个减号. 既然如此, 那撸一个简单的浏览器插件应当不难.

于是我花了一些业余时间, 从零入门, 写了一个简单的火狐插件jsproxy-firefox-extension, 项目地址是https://github.com/JimmyTinsley/jsproxy-firefox-extension. 目前还没有上架, 可以clone下来, 在火狐地址栏中访问about:debugging启用附加组件调试来加载临时扩展.

使用之前先点击工具栏上的图标进入附加组件设置界面, 设置一下需要使用的jsproxy地址. 然后访问一下这个地址进入Page Sandbox, 完成Service Worker的初始化, 之后就可以使用了.

目前实现的功能有:

• 当右键点击一个链接时, 可以选择通过jsproxy打开这个链接
• 当右键点击一段选中的文字时, 可以选择通过jsproxy的Google搜索这段文字, 如果这一段文字刚好是一个url, 则会使用jsproxy打开这个url.
• 当右键点击一张图片时, 可以选择通过jsproxy打开这张图片
• 在地址栏上加入一个功能按钮, 如果当前页面不是用jsproxy打开的, 那么点击它可以使用jsproxy打开; 反之可以将用jsproxy打开的页面去代理化.

开发的过程主要就是参照Mozilla官方的MDN和他们的插件范例, 模仿范例的代码结构再查找可用的API, 总体来说还比较顺畅. 由于对JS的async function以及Promise用法不太熟, 导致卡了一会儿, 其他的部分都没有遇到什么阻碍. 感叹一下, 前端的入门确实比后端快很多:joy:

就先写到这里, 如果之后还有新的功能特性, 我再来更新这篇文章.