# 浏览器采集插件登录方案备忘

> 状态：2026-09-07 记录。本文保留备选方案，不代表当前默认实现。

## 方案 A：网页确认 + PKCE 配对（备选，暂不启用）

1. 插件创建 3 分钟有效的连接请求，生成本地 PKCE verifier/challenge。
2. 插件打开固定的 Atlas `/extension-connect` 网页。
3. 网页复用 HttpOnly Web 会话确认连接；未登录时登录后继续。
4. 插件轮询请求状态，凭 verifier 换取独立 access/refresh token。

优点：Web refresh cookie 和 Web access token 永不交给扩展；扩展令牌可独立撤销。缺点：需要配对表、轮询端点、确认页、状态机和失败回收，当前阶段对“登录后采集”的简单需求而言复杂度过高。

## 方案 B：毛子 ERP 风格的网页登录态同步（当前采用）

1. 用户在插件点击登录。
2. 插件打开固定 Atlas ERP 网页；未登录时用户在该网页完成登录。
3. Web 登录或刷新会话后，把当前 access token 写到本站 `localStorage["atlas.extension.web-access"]`。
4. 插件每 2 秒从该 Atlas 网页标签读取该值；读取到后写入自己的 `chrome.storage.local`。
5. 插件用该 Bearer token 调用扩展会话校验接口；校验成功即显示采集操作。
6. 后续扩展 API 请求经后台统一附加 `Authorization: Bearer <token>`。

该流程不依赖 `chrome.identity`、`chromiumapp.org` 回调 URL 或用户配置的扩展 ID；扩展清单的公开 `key` 仅用于稳定扩展 ID。

## 安全取舍与边界

- 这是对项目“Web access token 不落持久化存储”规则的**维护者批准的、窄范围例外**，仅为自托管采集插件互操作。
- Token 仅写入 Atlas Web 自己的 origin，扩展只通过 `scripting.executeScript` 从其被打开的 Atlas 标签读取；不会读取 Cookie、refresh token、来源站点账号或来源站点 localStorage。
- 插件仍只取得短期 Web access token；收到 401 时清除插件缓存，用户需再次从 Atlas 网页同步新 Token。
- 当前阶段不应把该 Token 写入日志、数据库、Outbox、采集载荷或页面 DOM；生产部署必须将扩展 host permission 限定为正式 Atlas Web 域。
- 方案 A 保留为未来需要独立可撤销插件会话时的升级路径。