🐛 针对 WebDAV 修复 cookies 认证冲突 及 authType 支持

[CodFrm]

Summary

修复 #1297

WebDAV 同步/备份请求从 options.html 发起时，浏览器会自动携带目标域名的 cookies，导致与用户在浏览器中已登录的账户产生冲突（401 Unauthorized）。

通过 webdav 库提供的 getPatcher() API，patch fetch 调用强制设置 credentials: "omit"，确保 WebDAV 请求不携带任何浏览器 cookies，只通过 Authorization header（账号密码）进行认证。

Test plan

• 在浏览器中登录 Nextcloud 账户 A
• 在 ScriptCat 中配置 WebDAV 同步/备份到不同的 Nextcloud 账户 B
• 执行同步/备份，验证不再报 401 Unauthorized
• 验证正常的 WebDAV 同步/备份功能不受影响

[cyfung1031]

UI 未支持 none 和 token ??

---

WebDAV AuthType 四种方式比较

基本对比

	password	digest	none	token
传输方式	Base64 明文	哈希挑战响应	无认证	Bearer Token
密码暴露风险	🔴 高（需 HTTPS）	🟡 中	—	🟢 低
服务端支持	最广泛	较广泛	公开资源	少数服务
实现复杂度	最简单	中等	最简单	中等

---

各自适用场景

password（Basic Auth）

createClient(url, { authType: "password", username, password })

• 每次请求都带 Authorization: Basic base64(user:pass)
• 必须配合 HTTPS，否则密码裸奔
• 坚果云、大多数标准 WebDAV 服务都用这个

digest

createClient(url, { authType: "digest", username, password })

• 第一次请求服务端返回 nonce，客户端用 MD5 哈希响应
• 密码不直接传输，比 Basic 安全一点
• 但多账号时注意 nonce 状态隔离（每账号独立 client）
• Apache WebDAV 常用

none

createClient(url, { authType: "none" })

• 不发任何认证 header
• 只用于完全公开的 WebDAV 资源
• 或者你自己在 headers 里手动管理认证

token

createClient(url, { authType: "token", token: accessToken })

• 发送 Authorization: Bearer <token>
• 适合 OAuth2 流程，token 有过期时间需要刷新
• Nextcloud + OAuth2 app 可以用这个

---

安全性排序

none < password(HTTP) < digest < password(HTTPS) ≈ token

---

选择建议

普通 WebDAV 服务        → password（确保 HTTPS）
需要避免密码直接传输    → digest
公开资源 / 自定义认证   → none
OAuth2 / 现代云服务     → token
Nextcloud 生产环境      → token 或 password + App Password

[CodFrm]

看起来是的，都显示的账号/密码

[cyfung1031]

看起来是的，都显示的账号/密码

修好了
e79a233

ScriptCat旧代码真的乱糟糟。。。

[cyfung1031]

ScriptCat的奇怪排版导致 要 140px
明明内容没有那么阔

不过算了。就这样吧