PuerNya

> -- Blocking request (http://s.web2.qq.com/api/get_group_name_list_mask2?r=%7B%22hash%22%3A%22005400D20047003E%22%2C%22vfwebqq%22%3A%2274d55e6a2af3b0a6b36e362159ea54d7c216f5f4a0c06ef5c744011caa06768ed3b6d4e48e4be57e%22%7D) -- Client >>> Server (http://s.web2.qq.com/api/get_group_name_list_mask2?r=%7B%22hash%22%3A%22005400D20047003E%22%2C%22vfwebqq%22%3A%2274d55e6a2af3b0a6b36e362159ea54d7c216f5f4a0c06ef5c744011caa06768ed3b6d4e48e4be57e%22%7D) GET /api/get_group_name_list_mask2?r=%7B%22hash%22%3A%22005400D20047003E%22%2C%22vfwebqq%22%3A%2274d55e6a2af3b0a6b36e362159ea54d7c216f5f4a0c06ef5c744011caa06768ed3b6d4e48e4be57e%22%7D HTTP/1.1 Cookie: p_uin=o0294717557; pt4_token=N43sg0vF6wBzC6p9xDFhQkCn*9YsUfKCFZTL5xDbr*0_; p_skey=On*rPc0hd2qcS5Yglb9LpmWEbgmqc-IHbENQMH3IC8s_; RK=9TC0leDxYS; ptcz=50c1249ee22e241b328f8af1a0a013ca7a685d78bca07501dc8c98405221413c; uin=o0294717557; skey=@cIJjfYaLL; pt2gguin=o0294717557 Content-Length: 0 Host: s.web2.qq.com Accept-Encoding: gzip Referer: http://s.web2.qq.com/proxy.html?v=20130916001&callback=1&id=1...

收到酷安的通知没法直接拉起呢

> > > > 最新释出的 Magisk Canary 提供了 Zygisk API 并且禁止在 Zygisk 开启的同时使用 Riru 这让很多 Riru 模组赖以生存的环境变得不是那么良好，所以吞拿考虑一下提供 Zygisk 版本不？ > > 不如坐等rikka适配zygisk🐱 你好，两个干的是同一件事而且 Riru 加载时机比 Zygisk API 提供的早，谢谢

> @kaniwow zygisk版本，请测试下是否工作： https://app.circleci.com/pipelines/github/Tornaco/Thanox/175/workflows/186ed892-0e6e-4994-84c7-5c4875aa92b9/jobs/169/artifacts 好的 晚点测试

it's okay if there's a new metadata value named 'process' provided

after turning on the "find_process" option, I've gotten the process_path data, and I've found that the data seems display incorrectly. I've gotten some data like "\\Device\\HarddiskVolume3\\". Is that a feature...

> 我真是无语，我需要你给我在这扯这些么。我反馈的是“反向代理场景下，内网公网断连后无法恢复”。我仅仅是想反馈这个问题，至于是协议漏洞，还是程序bug，作为用户来说，我不在乎，我仅仅是反馈，断连后服务就不可用了。你跟我扯这么多TCP干嘛啊。另外，我寻思你也不是这个项目的Contributor啊，你说一堆什么玩意呀 协议实现天然不支持丢包恢复，本来就是无效反馈，你看不懂还怪人家扯 TCP，你才是莫名其妙吧……

> 我认为应该通过配置项添加允许的域，而不是允许所有，因为网传已经存在通过浏览器发起的对 Clash API 的攻击。 我们在 `experimental.clash_api.external_controller` 中已经设定了 Clash API 的监听范围，也通过 `experimental.clash_api.secret` 设定了校验密钥，再次设定控制域是否存在逻辑过于复杂且并无必要的情况？ 同时必须指出的是，不论是在稍低版本的 chromium 和 firefox 中还是透过后端程序发起的请求，此 CORS 校验并不会生效，因此它的影响力并没有那么大。 我认为，我们应该引导用户正确设定 Clash API 的监听范围并设定一定复杂度的校验密钥，从而规避可能存在的风险而不是对一个影响力本不大的 CORS 校验设计过于复杂的校验逻辑

我已理解并赞同你所说。让用户去配置他们所信任的面板域名并不是一个很坏的设定，我将新增一个配置项在 `experimantal.clash_api` 下以供用户配置他们的信任域。 另外我还有一个问题，我们是否需要在代码中硬编码一些开源的被广为使用的面板项目通过 gh page 或者 cf pages 托管的网络面板域名作为内置信任名单呢。比如：`haishanh/yacd` `MetaCubeX/Yacd-meta` `MetaCubeX/metacubexd`

@Tornaco 快进到重写隐匿 功能 直接 `hook System 的返回值` 来做到隐匿 而不是 `hook app 获取的 接口`