R524809
2.3 KiB
2.3 KiB
浏览器采集插件登录方案备忘
状态：2026-09-07 记录。本文保留备选方案，不代表当前默认实现。
方案 A：网页确认 + PKCE 配对（备选，暂不启用）
- 插件创建 3 分钟有效的连接请求，生成本地 PKCE verifier/challenge。
- 插件打开固定的 Atlas
/extension-connect网页。 - 网页复用 HttpOnly Web 会话确认连接；未登录时登录后继续。
- 插件轮询请求状态，凭 verifier 换取独立 access/refresh token。
优点：Web refresh cookie 和 Web access token 永不交给扩展；扩展令牌可独立撤销。缺点：需要配对表、轮询端点、确认页、状态机和失败回收，当前阶段对“登录后采集”的简单需求而言复杂度过高。
方案 B：毛子 ERP 风格的网页登录态同步（当前采用）
- 用户在插件点击登录。
- 插件打开固定 Atlas ERP 网页；未登录时用户在该网页完成登录。
- Web 登录或刷新会话后，把当前 access token 写到本站
localStorage["atlas.extension.web-access"]。 - 插件每 2 秒从该 Atlas 网页标签读取该值；读取到后写入自己的
chrome.storage.local。 - 插件用该 Bearer token 调用扩展会话校验接口；校验成功即显示采集操作。
- 后续扩展 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 保留为未来需要独立可撤销插件会话时的升级路径。