Add codex2api as a protocol-first OAuth source
This keeps the existing CPA, SUB2API, and contribution flows intact while introducing codex2api as a separate source that plugs into Step 7 and Step 10 through backend APIs instead of page DOM. The sidepanel now exposes codex2api settings, preserves the built-in local default through placeholder-only UI, and accepts user-provided public admin URLs. Step 7 now treats missing or invalid management secrets as terminal config errors so the flow stops instead of retrying needlessly. Constraint: New source must be additive and must not break existing CPA/SUB2API/contribution paths Rejected: Drive codex2api through admin page button clicks | too brittle against frontend DOM changes Rejected: Reuse contribution mode as a source surface | violates existing panelMode/runtime-mode boundary Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep codex2api on the protocol path unless its API becomes insufficient; do not add a panel content script without proving the protocol path cannot work Tested: npm test; targeted codex2api/auth retry loops repeated 40 times; full suite repeated 5 times Not-tested: Real browser run against a live codex2api instance with a real Admin Secret and OpenAI authorization
This commit is contained in:
+24
-9
@@ -22,7 +22,7 @@
|
||||
- 刷新 OAuth 链接并登录
|
||||
- 轮询登录验证码
|
||||
- 自动确认 OAuth 同意页
|
||||
- 把 localhost 回调提交到 CPA 或 SUB2API
|
||||
- 把 localhost 回调提交到 CPA、SUB2API 或 Codex2API
|
||||
|
||||
## 2. 核心运行参与者
|
||||
|
||||
@@ -152,6 +152,7 @@
|
||||
保存持久配置与账号运行历史:
|
||||
|
||||
- CPA / SUB2API 配置
|
||||
- Codex2API 配置
|
||||
- 邮箱 provider 配置
|
||||
- Hotmail 账号池
|
||||
- 2925 账号池
|
||||
@@ -166,7 +167,7 @@
|
||||
注意:
|
||||
|
||||
- `contributionMode` 不属于持久配置,也不参与导入/导出;它只存在于运行态
|
||||
- `panelMode` 仍然只表示 `cpa | sub2api` 来源,不能把贡献模式实现成新的来源枚举
|
||||
- `panelMode` 当前表示 `cpa | sub2api | codex2api` 三个来源;贡献模式仍不是新的来源枚举
|
||||
|
||||
当启用了独立的账号运行历史本地同步配置时,账号运行历史会通过 [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) 整体同步写入 `data/account-run-history.json` 快照文件,便于开发者直接查看完整记录。
|
||||
这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。
|
||||
@@ -189,10 +190,10 @@
|
||||
1. 用户点击顶部 `贡献`
|
||||
2. sidepanel 直接通过 `SET_CONTRIBUTION_MODE` 切换运行态,不再弹确认窗口
|
||||
3. 进入贡献模式后会强制 `panelMode = cpa`,并临时清空运行态 `customPassword`、禁用运行态账号记录快照同步
|
||||
4. sidepanel 隐藏 CPA 管理地址、管理密钥、SUB2API 配置、自定义密码、本地同步等普通模式配置,并禁用来源选择、配置菜单和记录入口
|
||||
4. sidepanel 隐藏 CPA 管理地址、管理密钥、SUB2API 配置、Codex2API 配置、自定义密码、本地同步等普通模式配置,并禁用来源选择、配置菜单和记录入口
|
||||
5. 用户点击 `开始贡献` 后,不再单独走一条旁路 OAuth 流程,而是直接复用顶部 `自动` 的同一套主自动流
|
||||
6. 步骤 1~6 仍按原来的注册自动化执行
|
||||
7. 当主流程进入步骤 7 时,后台改为调用公开接口 `POST https://apikey.qzz.io/oauth/api/start` 申请贡献登录地址,而不是去 CPA / SUB2API 面板刷新 OAuth
|
||||
7. 当主流程进入步骤 7 时,后台改为调用公开接口 `POST https://apikey.qzz.io/oauth/api/start` 申请贡献登录地址,而不是去 CPA / SUB2API / Codex2API 来源刷新 OAuth
|
||||
8. 步骤 7 拿到 `session_id / auth_url / state` 后,继续沿用原有登录链路进入授权页
|
||||
9. 步骤 9 仍负责捕获 localhost callback;贡献模式下后台也会持续监听导航变化,必要时提前兼容处理 callback
|
||||
10. 步骤 10 在贡献模式下不再打开 CPA 管理页,而是围绕公开贡献会话做 callback 提交兼容和最终状态确认;当状态进入 `auto_approved / auto_rejected / manual_review_required / expired / error` 时结束
|
||||
@@ -378,7 +379,10 @@
|
||||
|
||||
流程:
|
||||
|
||||
1. 通过 CPA / SUB2API 刷新 OAuth 地址
|
||||
1. 按当前来源刷新 OAuth 地址:
|
||||
- CPA:打开管理页并读取 OAuth 地址
|
||||
- SUB2API:打开后台并生成 OAuth 地址
|
||||
- Codex2API:直接调用后台协议 `/api/admin/oauth/generate-auth-url`
|
||||
2. 打开最新 OAuth 链接
|
||||
3. 登录;如果进入密码页且当前有密码,则填写并提交密码;如果当前没有密码但检测到一次性验证码入口,则直接切换到一次性验证码登录
|
||||
4. 确保真正进入验证码页
|
||||
@@ -388,7 +392,7 @@
|
||||
|
||||
贡献模式补充:
|
||||
|
||||
- 贡献模式下,步骤 7 不再从 CPA / SUB2API 面板刷新 OAuth,而是直接调用公开贡献接口 `/oauth/api/start`
|
||||
- 贡献模式下,步骤 7 不再从 CPA / SUB2API / Codex2API 来源刷新 OAuth,而是直接调用公开贡献接口 `/oauth/api/start`
|
||||
- 贡献接口返回的 `auth_url` 会写回运行态 `oauthUrl`,后续步骤 7 / 8 / 9 继续复用现有授权链路
|
||||
|
||||
### Step 8
|
||||
@@ -435,15 +439,22 @@
|
||||
流程:
|
||||
|
||||
1. 校验 localhost callback 是否有效
|
||||
2. 判断是 CPA 还是 SUB2API
|
||||
3. 打开相应后台
|
||||
4. 提交回调地址
|
||||
2. 判断当前来源是 CPA、SUB2API 还是 Codex2API
|
||||
3. CPA / SUB2API 打开相应后台;Codex2API 直接走协议分支,不打开后台页面
|
||||
4. 提交回调地址或等价的授权码交换请求
|
||||
5. 仅当出现精确成功徽标,且该徽标不是红色/错误态、页面上也没有同时可见的失败提示时,才判定成功
|
||||
6. 识别 `认证失败:*`、`认证失败: timeout of 30000ms exceeded`、`回调 URL 提交失败: oauth flow is not pending` 等失败提示并立即报错
|
||||
7. 完成平台侧验证
|
||||
8. 追加账号运行历史成功记录
|
||||
9. 做成功后的清理与标记
|
||||
|
||||
Codex2API 补充:
|
||||
|
||||
- 步骤 7 直接调用 `POST /api/admin/oauth/generate-auth-url` 获取 `auth_url / session_id`
|
||||
- 授权页仍沿用现有 OpenAI 登录、验证码、OAuth 同意页与 localhost callback 主链
|
||||
- 步骤 10 直接调用 `POST /api/admin/oauth/exchange-code`,用 callback 中的 `code / state` 完成账号创建
|
||||
- Codex2API 这条来源不新增 panel content script,也不依赖“添加账号 -> OAuth 授权 -> 生成授权链接”页面按钮 DOM
|
||||
|
||||
贡献模式补充:
|
||||
|
||||
- 贡献模式下,步骤 10 不再打开 CPA 管理页
|
||||
@@ -677,6 +688,10 @@
|
||||
5. Step 4 / 7 的验证码流
|
||||
6. 成功收尾逻辑
|
||||
|
||||
如果来源本身提供稳定协议接口,还必须额外判断:
|
||||
|
||||
7. 是否可以不打开来源后台页面,直接把步骤 7 / 10 收敛到协议分支
|
||||
|
||||
### 新增配置项
|
||||
|
||||
必须同时检查:
|
||||
|
||||
Reference in New Issue
Block a user