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