贡献功能开发
This commit is contained in:
QLHazyCoder
+56
@@ -37,6 +37,8 @@
|
||||
- 向后台发送命令
|
||||
- 接收后台广播并更新 UI
|
||||
- 动态渲染步骤列表
|
||||
- 管理顶部“贡献”按钮与贡献模式主面板；贡献模式本身是 sidepanel 的运行态 UI 模式，不是新的 `panelMode` 来源
|
||||
- 在贡献模式下复用同一套主自动流程启动，并在面板内展示贡献链路的 `OAUTH / 回调 / 总状态` 三块实时状态
|
||||
- 在日志区通过“记录”按钮打开独立的邮箱记录覆盖层，并展示成功/失败/停止/重试统计与分页列表
|
||||
- 查询 GitHub Releases 并展示更新卡片；当前更新服务会区分 `Pro` 与 legacy `v` 两个版本族，排序时优先保持版本族语义一致，同时会在读取缓存后重新排序，避免旧缓存把 `v` 版本误显示为比 `Pro` 更新
|
||||
|
||||
@@ -118,6 +120,15 @@
|
||||
保存运行态：
|
||||
|
||||
- 当前步骤状态
|
||||
- 当前 sidepanel UI 模式 `contributionMode`
|
||||
- 贡献 OAuth 会话字段：
|
||||
- `contributionSessionId`
|
||||
- `contributionAuthUrl`
|
||||
- `contributionAuthState`
|
||||
- `contributionCallbackUrl`
|
||||
- `contributionStatus`
|
||||
- `contributionStatusMessage`
|
||||
- `contributionLastPollAt`
|
||||
- OAuth 链接
|
||||
- 当前邮箱 / 密码
|
||||
- localhost 回调地址
|
||||
@@ -141,6 +152,11 @@
|
||||
- 账号运行历史 `accountRunHistory`（以邮箱为主键，保存该邮箱最近一次状态：成功/失败/停止）
|
||||
- 账号运行历史本地同步开关与 helper 地址
|
||||
|
||||
注意：
|
||||
|
||||
- `contributionMode` 不属于持久配置，也不参与导入/导出；它只存在于运行态
|
||||
- `panelMode` 仍然只表示 `cpa | sub2api` 来源，不能把贡献模式实现成新的来源枚举
|
||||
|
||||
当启用了独立的账号运行历史本地同步配置时，账号运行历史会通过 [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) 整体同步写入 `data/account-run-history.json` 快照文件，便于开发者直接查看完整记录。
|
||||
这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。
|
||||
|
||||
@@ -155,6 +171,35 @@
|
||||
- `ICLOUD_LOGIN_REQUIRED`
|
||||
- `ICLOUD_ALIASES_CHANGED`
|
||||
|
||||
### 4.4 贡献模式链路
|
||||
|
||||
贡献模式的目标不是新增一个 provider，而是在 sidepanel 内开启一套“贡献账号”专用 UI，并把公开贡献服务并进原有 10 步主链：
|
||||
|
||||
1. 用户点击顶部 `贡献`
|
||||
2. sidepanel 复用现有 `openConfirmModal(...)` 打开确认弹窗
|
||||
3. 用户确认后，后台通过 `SET_CONTRIBUTION_MODE` 切换运行态
|
||||
4. 进入贡献模式后会强制 `panelMode = cpa`，并临时清空运行态 `customPassword`、禁用运行态账号记录快照同步
|
||||
5. sidepanel 隐藏 CPA 管理地址、管理密钥、SUB2API 配置、自定义密码、本地同步等普通模式配置，并禁用来源选择、配置菜单和记录入口
|
||||
6. 用户点击 `开始贡献` 后，不再单独走一条旁路 OAuth 流程，而是直接复用顶部 `自动` 的同一套主自动流
|
||||
7. 步骤 1~6 仍按原来的注册自动化执行
|
||||
8. 当主流程进入步骤 7 时，后台改为调用公开接口 `POST https://apikey.qzz.io/oauth/api/start` 申请贡献登录地址，而不是去 CPA / SUB2API 面板刷新 OAuth
|
||||
9. 步骤 7 拿到 `session_id / auth_url / state` 后，继续沿用原有登录链路进入授权页
|
||||
10. 步骤 9 仍负责捕获 localhost callback；贡献模式下后台也会持续监听导航变化，必要时提前兼容处理 callback
|
||||
11. 步骤 10 在贡献模式下不再打开 CPA 管理页，而是围绕公开贡献会话做 callback 提交兼容和最终状态确认；当状态进入 `auto_approved / auto_rejected / manual_review_required / expired / error` 时结束
|
||||
12. 当前服务端如果返回“无需手动提交 callback”，扩展会把它视为兼容成功态，而不是报错
|
||||
13. `已有认证文件？前往上传` 继续打开 `https://apikey.qzz.io/`
|
||||
14. `退出贡献模式` 会清理贡献会话相关运行态，`重置` 只重置主流程状态，不会自动退出贡献模式
|
||||
|
||||
这条链路的关键边界是：
|
||||
|
||||
- 扩展会调用公开贡献 API，但这条调用被折叠进主 10 步自动链，而不是额外分出一条独立“贡献 OAuth 小流程”
|
||||
- 扩展不会保存 token
|
||||
- 扩展不会持有任何管理密钥
|
||||
- 扩展代码中不能直接调用 `/v0/management/*`
|
||||
- 扩展不会直接访问生产管理面或生产 auth-dir
|
||||
- 安全边界仍然在服务端；扩展只负责公开 OAuth 贡献前端流程
|
||||
- 退出贡献模式后，要恢复普通模式 UI，并恢复持久配置中的自定义密码/本地同步偏好
|
||||
|
||||
## 5. 内容脚本通信链路
|
||||
|
||||
### 5.1 READY 机制
|
||||
@@ -303,6 +348,11 @@
|
||||
6. 自动运行一旦进入步骤 7 之后的链路，若后续步骤报错且认证页未进入 `https://auth.openai.com/add-phone`，则统一回到步骤 7 重新开始授权流程
|
||||
7. CPA 回调阶段固定为步骤 9，不再支持“第七步回调”跳过步骤 7/8
|
||||
|
||||
贡献模式补充：
|
||||
|
||||
- 贡献模式下，步骤 7 不再从 CPA / SUB2API 面板刷新 OAuth，而是直接调用公开贡献接口 `/oauth/api/start`
|
||||
- 贡献接口返回的 `auth_url` 会写回运行态 `oauthUrl`，后续步骤 7 / 8 / 9 继续复用现有授权链路
|
||||
|
||||
### Step 8
|
||||
|
||||
文件：
|
||||
@@ -350,6 +400,12 @@
|
||||
8. 追加账号运行历史成功记录
|
||||
9. 做成功后的清理与标记
|
||||
|
||||
贡献模式补充：
|
||||
|
||||
- 贡献模式下，步骤 10 不再打开 CPA 管理页
|
||||
- 步骤 10 会先尝试提交已捕获的 callback URL，随后轮询公开贡献状态，直到进入最终态
|
||||
- `auto_approved` 与 `manual_review_required` 视为主流程完成；`auto_rejected / expired / error` 视为当前轮失败
|
||||
|
||||
## 7. 邮箱与 provider 链路
|
||||
|
||||
### 7.1 2026-04-17 补充：Gmail / 2925 统一别名邮箱链路
|
||||
|
||||
Reference in New Issue
Block a user