Expand seller store functionality
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
# 浏览器采集插件登录方案备忘
|
||||
|
||||
> 状态: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 保留为未来需要独立可撤销插件会话时的升级路径。
|
||||
Reference in New Issue
Block a user