Skip to content

[v1.4] 修正 Subscribe 的 Script 的 静默更新#1201

Merged
CodFrm merged 9 commits intoscriptscat:release/v1.4from
cyfung1031:pr-fix-regular-update-003
Mar 29, 2026
Merged

[v1.4] 修正 Subscribe 的 Script 的 静默更新#1201
CodFrm merged 9 commits intoscriptscat:release/v1.4from
cyfung1031:pr-fix-regular-update-003

Conversation

@cyfung1031
Copy link
Copy Markdown
Collaborator

No description provided.

@CodFrm
Copy link
Copy Markdown
Member

CodFrm commented Feb 12, 2026

感觉是老的检查更新逻辑丢失了呀,订阅脚本默认就是静默更新,不受配置控制(又似乎是后面把静默更新的逻辑拿出来作为配置项了),但是文档中的描述是这个功能所期望的效果

订阅脚本仅会在安装时弹出安装界面由用户确认订阅,但后续的更新采用静默更新的方式,除非connect权限发生改变,否则不会弹出更新界面由用户确认。
一个订阅脚本可以描述所需要的多个脚本的安装链接,通过订阅模式安装的脚本使用静默安装,不会弹出确认安装页面,所安装的脚本也会展示在脚本列表中,但是connect权限会使用订阅中所声明的connect,而不会使用脚本自身的connect权限。

https://docs.scriptcat.org/docs/dev/subscribe/

@cyfung1031
Copy link
Copy Markdown
Collaborator Author

cyfung1031 commented Feb 12, 2026

所以,即使 静默更新 没有打勾,订阅脚本 是自动预设为 静默更新?

现在PR是

静默更新 没打开 : 订阅脚本每次更新都会弹出来
静默更新 有打开 : 订阅脚本的更新没改 @connect 都会自动安装,否则弹出来

静默更新 有打开 : 订阅脚本的脚本会根据自己的 @connect 和 订阅脚本的 @connect 判断能否 静默更新

也就是说,在 静默更新 有打开 時,如果 订阅脚本的脚本 没 domainA, 订阅脚本 也没有 domainA, 就不能 静默更新
其中一个有 domainA 都可以 静默更新

订阅脚本先更新至 有domainA后, 订阅脚本的脚本能 静默更新


我觉得这样跟你上面引用的是一样呀
只是我考虑的是

  • 订阅脚本的@connect更新
  • 订阅脚本的更新
  • 订阅脚本的Script脚本的@connect更新
  • 订阅脚本的Script脚本的更新

@cyfung1031 cyfung1031 changed the title [v1.3] 修正 Subscribe 的 Script 的 静默更新 [v1.4] 修正 Subscribe 的 Script 的 静默更新 Feb 24, 2026
@cyfung1031 cyfung1031 changed the base branch from release/v1.3 to release/v1.4 March 15, 2026 04:59
@CodFrm
Copy link
Copy Markdown
Member

CodFrm commented Mar 29, 2026

所以,即使 静默更新 没有打勾,订阅脚本 是自动预设为 静默更新?

现在PR是

静默更新 没打开 : 订阅脚本每次更新都会弹出来 静默更新 有打开 : 订阅脚本的更新没改 @connect 都会自动安装,否则弹出来

静默更新 有打开 : 订阅脚本的脚本会根据自己的 @connect 和 订阅脚本的 @connect 判断能否 静默更新

也就是说,在 静默更新 有打开 時,如果 订阅脚本的脚本 没 domainA, 订阅脚本 也没有 domainA, 就不能 静默更新 其中一个有 domainA 都可以 静默更新

订阅脚本先更新至 有domainA后, 订阅脚本的脚本能 静默更新

我觉得这样跟你上面引用的是一样呀 只是我考虑的是

  • 订阅脚本的@connect更新
  • 订阅脚本的更新
  • 订阅脚本的Script脚本的@connect更新
  • 订阅脚本的Script脚本的更新

是这样,只是这个订阅的静默更新,不依赖静默更新的开关;不过你这样也合理

@CodFrm
Copy link
Copy Markdown
Member

CodFrm commented Mar 29, 2026

还有一点,订阅的脚本的@connect,是跟随订阅的,而不是使用脚本的@connect,所以当时有这个设计

https://docs.scriptcat.org/docs/dev/subscribe/

一个订阅脚本可以描述所需要的多个脚本的安装链接,通过订阅模式安装的脚本使用静默安装,不会弹出确认安装页面,所安装的脚本也会展示在脚本列表中,但是connect权限会使用订阅中所声明的connect,而不会使用脚本自身的connect权限。

@CodFrm
Copy link
Copy Markdown
Member

CodFrm commented Mar 29, 2026

文档描述有点问题:

订阅的脚本使用静默的方式进行安装,订阅新增/删除脚本时仅会弹出一个通知,不会再次由用户进行确认,脚本的更新机制不发生变化需要由用户确认,若用户勾选了设置->非重要变更静默更新脚本的选项,则按照改规则进行更新。由于静默更新的机制,请选择安全且值得信任的订阅方。

感觉是不是写错了,读都读不通畅,这两个逻辑是冲突的,重新整理一下:

一个订阅脚本可以描述所需要的多个脚本的安装链接,通过订阅模式安装的脚本使用静默安装,不会弹出确认安装页面,所安装的脚本也会展示在脚本列表中,但是connect权限会使用订阅中所声明的connect,而不会使用脚本自身的connect权限。

订阅的脚本使用静默的方式进行安装,订阅新增/删除脚本时仅会弹出一个通知,不会再次由用户进行确认;由于静默更新的机制,请选择安全且值得信任的订阅方。

QQ_1774766190015

根据文档设计,订阅脚本应始终静默更新,不受「非重要变更静默更新脚本」
开关控制;订阅下脚本的 connect 权限完全由订阅的 connect 覆盖。

- subscribe.ts: 订阅本身更新去掉 toggle 依赖,始终静默(除非 connect 变化)
- script.ts: 订阅下脚本更新始终静默,不检查 toggle 和 connect
- gm_api.ts: 运行时 GM_xmlhttpRequest/GM_cookie 的 connect 权限使用订阅声明的覆盖
- utils.ts: 简化 checkSilenceUpdate,移除不再需要的 subscribeMetadata 参数
@CodFrm
Copy link
Copy Markdown
Member

CodFrm commented Mar 29, 2026

根据订阅模式文档的设计,对订阅相关的静默更新和 connect 权限逻辑做了修正:

改动说明

1. 订阅本身更新:去掉 toggle 依赖

subscribe.ts:trySilenceUpdate 不再检查「非重要变更静默更新脚本」开关,订阅始终静默更新(除非 @connect 新增了域)。

2. 订阅下脚本更新:始终静默

script.ts:openUpdateOrInstallPage 中,若脚本有 subscribeUrl,直接静默更新,不检查 toggle 和 connect。信任关系由订阅建立,脚本自身的更新无需再次确认。

3. 运行时 connect 权限覆盖

gm_api.ts:parseRequest 中,订阅脚本的 @connect 使用订阅声明的 @connect 覆盖脚本自身的,确保 GM_xmlhttpRequest / GM_cookie 的权限判断与文档一致。

4. 简化 checkSilenceUpdate

移除了 subscribeMetadata 第三个参数(不再需要),回归为简洁的两参数版本。

测试

新增 4 个测试覆盖 connect 覆盖场景,全量 888 个测试通过。

@CodFrm CodFrm merged commit a3c2581 into scriptscat:release/v1.4 Mar 29, 2026
3 of 4 checks passed
@cyfung1031
Copy link
Copy Markdown
Collaborator Author

不再检查「非重要变更静默更新脚本」开关,订阅始终静默更新

明白了

不过这样的话, 静默更新 可能会直接覆盖掉用户自行改动过的代码
但这个是后话。先不处理。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants