sing-box
sing-box copied to clipboard
SagerNet
chore: add new cors response
自从 chrome 98 开始，google 提出了一个新的功能，对专用网络资源访问进行预检 ，它的前身是来自 W3C 社区的 此草案 。在高版本 chrome 中已出现因此无法使用网络面板进行控制的情况（特指搭载在开放网络上的公用网络面板而非由核心拉起的本地网络面板），故对 Preflight request 添加相应响应头，使浏览器按预期进行工作。
我认为应该通过配置项添加允许的域，而不是允许所有，因为网传已经存在通过浏览器发起的对 Clash API 的攻击。
我们在 experimental.clash_api.external_controller 中已经设定了 Clash API 的监听范围，也通过 experimental.clash_api.secret 设定了校验密钥，再次设定控制域是否存在逻辑过于复杂且并无必要的情况？
同时必须指出的是，不论是在稍低版本的 chromium 和 firefox 中还是透过后端程序发起的请求，此 CORS 校验并不会生效，因此它的影响力并没有那么大。
我认为，我们应该引导用户正确设定 Clash API 的监听范围并设定一定复杂度的校验密钥，从而规避可能存在的风险而不是对一个影响力本不大的 CORS 校验设计过于复杂的校验逻辑
你似乎没有把握住诸如此类攻击的运作原理，浏览器对本机 API 发起的请求是建立在绝大多数用户并不会改动端口和秘钥的基础上的。
你对于增加在新版浏览器上安全设定的简单计划表述为 过度复杂和并无必要，这点让我有些费解。第二段的内容也让我纳闷，新的 API 并不会影响在旧版浏览器上的攻击，所以没有必要进行对应设置，这个逻辑有些令人捉摸不透。
设定面板的域名明显比秘钥更为方便，哪里复杂不必要？因为秘钥只需要口头 “引导” 设置，不允许所有请求却增加了 无法作出任何贡献也理解不了配置的最终用户 的使用成本，底层逻辑是一种开源项目应该服务小白来换取非道德的影响力的狗稍。
作为一个开发者，建议你好好学习如何使用简体中文，避免写出这种看起来像文游一样的东西。
我已理解并赞同你所说。让用户去配置他们所信任的面板域名并不是一个很坏的设定，我将新增一个配置项在 experimantal.clash_api 下以供用户配置他们的信任域。
另外我还有一个问题，我们是否需要在代码中硬编码一些开源的被广为使用的面板项目通过 gh page 或者 cf pages 托管的网络面板域名作为内置信任名单呢。比如：haishanh/yacd MetaCubeX/Yacd-meta MetaCubeX/metacubexd