feat: allow to use custom rootPath

[hellodword]

No description provided.

[cwxiaos]

请问这个是出于安全考虑还是别的目的

[hellodword]

尽管有这样的代码

bark-worker/main.js

Lines 7 to 8 in 93a7219

	// 这里决定是否允许新建设备
	const isAllowNewDevice = false

但很难限制别人使用，因为至少无法限制他人消耗 Cloudflare workers 的额度，而如果利用 HTTPS、rootPath 和 page rules，就相当于增加了一种保护，只有知道确切路径的人才能产生有效的 Cloudflare workers 请求。这是一种 obscurity，但很有效。

[hellodword]

笔误，不是 page rules，是 Workers Routes

例如可以是 URL pattern https://abc.example.org/123456* 对应 bark-worker

https://developers.cloudflare.com/workers/configuration/routing/routes/

[cwxiaos]

经过测试，实际上利用Cloudflare 的WAF和Rules Rewrite也可以实现这一功能，所以为了代码的性能和稳定性考虑，后续可能会移除这部分代码

另外本项目主要还是bark-server的兼容实现，会尽量保持和原项目功能的一致性

因此对于安全上的考虑，后续会按这样的思路处理：

1.路径重定向，程序本体不做处理，类似于bark-server可以使用nginx做反代，利用Cloudflare的类似的功能来实现，这部分后续会单独写一个文档

2.Basic Auth,这是bark-server的功能，后续会加入到bark-worker中

实际上在Cloudflare网络上运行的程序应该还是相对安全的，同时为了解决一些存在了很久的的bug，后续会重写参数解析部分，到时候综合考虑这一功能的实现方式

[hellodword]

Workers Routes 我没找到具体的限制数据，但 Page Rules 是有还算严格的数量限制的 https://developers.cloudflare.com/rules/page-rules/ ，所以个人觉得 Workers Routes 值得保留。

---

重写的话可以考虑兼顾 wrangler 部署和普通用户手动部署，带入编译的能力，普通用户不关心代码可以让他们复制粘贴 dist，而开发者的体验就好太多了，例如

bark-worker/main.js

Lines 111 to 114 in c0f1369

	this.version = "v2.1.0"
	this.build = "2024-06-16 00:54:29"
	this.arch = "js"
	this.commit = "ebedc4f5174bfe5f22042de6101391c88aaad4c8"

愿意引入 nodejs 和 wrangler 的话，路由、参数解析会有很多库和兼容 CF 的 serverless 框架可以用，也方便处理类型和测试

也不需要维护两份差不多的代码，可以考虑 环境变量

bark-worker/main.js

Lines 7 to 10 in c0f1369

	// 这里决定是否允许新建设备
	const isAllowNewDevice = false
	// 是否允许查询设备数量
	const isAllowQueryNums = false

另外说不定可以通过 CF worker pages 加个前端和鉴权实现 这类功能 ，例如用 hono 之类的框架，哈哈