|
|
4a01297dfe
|
fix(安全)★★: 主进程零导航拦截 —— 加 will-navigate / 新窗口拒绝 + 单实例锁
**主进程此前没有任何守卫**（实测 grep 0 命中：setWindowOpenHandler、
will-navigate、requestSingleInstanceLock 全无）。
在 `loadFile(dist/index.html)` 下，邮件正文里的链接（react-markdown 会渲染
`<a href>`）点下去会**在应用窗口里导航走** —— 一个 `href="https://…"` 就足以
把整个应用窗口变成浏览器，而窗口标题与 preload 注入的 API base/token
全部暴露在那个站点上。
★ **本条防的不是 XSS**：`markdown-xss` 守的是渲染层（无 rehype-raw、
defaultUrlTransform 中和 javascript:），**目前没有 XSS 面**。
这里防的是**导航逃逸** —— 让外部站点**借用**这个窗口与 preload 上下文。
两者失效方式不同，所以分开钉。
**① setWindowOpenHandler** ⇒ 一律 `deny`，地址交系统浏览器。
`allow` 会给那个站点一个**带 preload 的窗口**。
**② will-navigate** ⇒ 拦下并 preventDefault。
★ 但必须**放行本应用自己的加载**（prod 的 `file://` / dev 的 `DEV_URL`）
—— 只会 preventDefault 的实现会把应用自己锁死，首屏进不去。
这是「过严的守卫同样是缺陷」，判据专门为它加了一格。
**③ 外跳只放行 http/https**：file: / javascript: / 自定义协议交给
`shell.openExternal` 意图不可控；`new URL()` 对畸形输入会抛，必须 catch。
**④ requestSingleInstanceLock**：双击图标此前会起**两个进程** ——
两条 SSE 连接、两套 `accounts.json` 并发写入（那个文件是 tmp+rename 原子写，
并发即「后写的赢」），而用户以为只有一扇窗。
**同时修的两处双提交**（形状与 ④ 同源，都是「busy/state 要到提交后才为真」）：
· PermissionPanel.submit：审批是本工程**唯一带副作用且不可撤销**的动作
⇒ 同帧两次激活会发出**两条** decidePermission（服务端记两次账）。
照同文件 ForwardBar 的 `inFlight` 形状改。
· Attachments.handleFiles：`uploading` 只加在按钮的 disabled 上，
`<input type=file>` 本身无闸门 ⇒ 上传期间重入会拿到**上一次的 items 闭包**
⇒ onChange 把上一次结果整批覆盖，表现为「附件少了」且**无任何提示**。
★ 清 `input.value` 必须与闸门**成对**提前：只提前清而不加闸门，
会亲手制造「上传中重选同一文件 ⇒ value 已空 ⇒ change 照触发 ⇒ 二次上传」。
**判据（新建 main-process-security.test.mjs，14 格，已接线）**
按括号配对取函数体/实参，**不用** `\{[\s\S]{0,80}` 窗口（§1 第三次露头）。
变异测试 **10 个全部抓住**：去掉 deny / 去掉 preventDefault / 守卫写死不放行自己 /
放开所有 scheme / 拿不到锁不退出 / sandbox:false / contextIsolation:false /
second-instance 删 show() / 删整个 if / 删 restore()。
★ PermissionPanel 那条新判据第一版是**假绿**：`fireEvent.click` 连发两次
（不在 act 里）**删掉闸门也照样绿** —— 两次 fireEvent 之间 React 提交了一次，
第二次点到的是已 disabled 的按钮。必须放进**同一个 act**（同批次、不提交）
才复现。`userEvent.click` 每次都 await 一轮 ⇒ 它测不到同帧。
这条已写进判据注释，免得下一个人再写一次。
**边界 / 未做**
· 这些是**静态**断言，证明守卫被写下来了，**不证明运行时生效**（那要真起窗口点链接）。
· 没有把 webPreferences 的值当"够不够安全"来评审 —— 那属于安全评审，不属可机检；
本条只钉「不许被放松」。
· X-2（index.html 无 CSP）没做：首帧防闪屏那段内联脚本要求 'unsafe-inline'，
加 CSP 是在**降低**强度的前提下加一层，值得单独一轮 + 真机验闪屏，不夹在本次。
|
2026-10-03 11:33:51 +08:00 |
|
|
|
addde97600
|
feat(electron): 多账号第一纵切 —— 账号存储/选择器/聚合收件箱
按 docs/MULTI-ACCOUNT-PLAN.md 实现客户端多账号的前半段（SSE 多连接与
写信账号切换留作下一轮）。
- `src/lib/accounts.ts`：纯逻辑（地址规范化、身份判重、默认账号、聚合合并），
16 条测试钉住每条判据（含反向对照）。
- 持久化在主进程：`userData/accounts.json`，**原子写**（临时文件 + rename）+
0600。不落 localStorage：那份存储渲染层任何脚本都可读，且 file:// 与
http:// 是两套。无 IPC 时（浏览器）退到 localStorage 并在界面**如实写明**。
- 取信：单账号走原路径（逐字节不变）；聚合时**每账号各一次请求、各带自己的
令牌**（`fetchWithAuth`，不碰认证单例，避免并发串号）。
- ★ 只合并**同一网关**的账号：跨网关的邮件混进列表后点开会去问当前账号的
服务器（404，或 mail_id 撞上就打开了别人的信）。如实排除 + 列表上方说明。
- ★ 部分失败可见：某账号取不到时给出账号名与原因 —— 静默丢掉它会让聚合列表
少一整份邮件而界面看起来完全正常。
- `API_BASE` 改为 `let`（切换账号要换网关），api 层不得缓存它
（`client.ts` 的 `const BASE` 快照已改成每次读）。
- UI：列表头下拉（≥2 个可用账号才出现「全部邮箱」）+ 账号徽标 + 账号页
「多账号」一段（添加前调 /auth/me 验证，401 当场拒绝，不写进列表）。
- 测试：vitest 230 通过（原 222 + 新 8）、`test/lib/accounts.test.mjs` 16 通过、
typecheck 通过。新增 `test/manual/multi-account-verify.mjs`（真起打包产物 +
两个真实账号，判据落在网络层：聚合必须每账号各一次请求且各带自己的令牌）。
|
2026-09-13 06:16:59 +08:00 |
|
|
|
8b2206ed53
|
fix(electron): Phase 3 验收抓到的两个静默缺陷 —— 白屏与登录
Phase 3（写信 + 附件 + 权限面板）的验收脚本第一次跑就把这两件事翻出来了，
两个都**表现正常**：进程活着、窗口标题对、接口能通，只有结果不对。
## 1. 打包后的应用是白屏（vite 的 base 缺省值）
`vite.config.ts` 没设 `base`，Vite 按默认的 `/` 生成 `src="/assets/index-xxx.js"`。
同一份 dist 有两个宿主：网关在 `/` 下伺服它（Web 正常），Electron 用 `loadFile()`
从 **file:///…/dist/index.html** 加载它 —— 绝对路径在那儿解析成
`file:///assets/index-xxx.js`（不存在），**JS 根本没加载**。
现场：`#root` 里一个子节点都没有。没有报错对话框，控制台里只有一条不起眼的
资源加载失败。而当时所有既有检查都是绿的：`npm run build` 成功、deb 元数据检查、
asar 内容清点（**它们只看文件在不在，不看文件引用什么**）。
修法：`base: './'` —— 两边都对（Web 在 /index.html 里 `./assets/x.js` → `/assets/x.js`；
Electron 在 dist/index.html 里 → `dist/assets/x.js`）。
## 2. 桌面壳用账号密码登录是断的，而且静默失败
账号密码登录靠 `SameSite=Lax` 的会话 Cookie，而桌面壳的页面是 `file://`
（**不透明源**）—— Chromium 按第三方上下文处理它，Cookie **不予存储**。
实测现场：`POST /auth/login` 返 **200**、响应体能读出用户名，但 `document.cookie`
是空的，紧接着的 `/auth/me` 返 **401**；界面停在登录页，看起来像「密码错了」，
而同样的账号密码用 curl 登录是成功的。所以这不是凭据问题。
修法：桌面壳里**不再给账号密码表**（一个必然失败的按钮比没有更糟），改成粘贴
**用户密钥**（`Authorization: Bearer`，桌面端本来就该这么用）：
- preload 显式声明 `__AGENTMAIL_SHELL__ = 'desktop'`（宿主契约，而不是让渲染层
sniff 协议；顺带让 jsdom 里可测 —— 那里的 `location.protocol` 不可重写）
- 新增 `authStore.loginWithKey`：成功后才留下令牌，失败**还原**（否则之后每个请求
都会带上这个坏 key 并 401，而人看到的是「重输一次也不行」）
- 顺手修了 label 与 input 没有关联（`htmlFor`/`id`）—— 无障碍缺陷，也让测试能按标签查
## 验收
- 结构性守卫进 `npm test`（`test/packaging.test.mjs`，不需要浏览器）：base 必须是
相对路径、产物里不能有绝对资源引用、**安装包里的 dist 与当前构建一致**
（前端改了没重打包时，装上去的人看到的是旧界面，两边不一致却谁都不报错）。
判据自检过：把 base 改回 `/` 或把产物改回绝对路径，各自都能让对应那条变红。
- 组件测试 6 条（两种壳的形态、密钥成功/失败、空密钥不可提交）。
- `test/manual/desktop-phase3-verify.mjs`：真起打包好的应用（xvfb + CDP），
一条贯穿的链 —— 用桌面 UI 写信带附件 → 外部核验信与附件真到了网关 →
这封信触发 zcode 的真实授权请求 → 在桌面**授权面板**里点同意 →
外部核验 **Agent 真的执行了**（标记文件出现）。第二次跑 14/14 全绿。
- 客户端全量 222/222；网关换新产物后 Web 依旧正常（相对路径在 `/` 下同样成立，
实测渲染出收件箱、无控制台错误），并真发一封邮件确认回信到达。
## 判据自己的错（记一笔）
第一次跑时「附件真的挂在信上」报红，而库里那 41 字节的附件**明明挂在信上** ——
我把端点写成了 `/me/mail/{id}`（不存在，404），正确是 `/mail/{id}`。
判据用错端点时以「附件是空的」现形，看起来像功能 bug。
另：`pkill -f 'agentmail-web'` 会把**自己这条命令**也杀掉（命令行里含同样的字符串），
表现是「脚本没有任何输出、退出码 143」。改用端口定位（`ss -tlnp | grep :9223`）。
|
2026-09-12 20:25:00 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
