Problem Statement
当前管理面仍然是单一 ADMIN_TOKEN 登录模型。/api/admin/* 全部依赖管理员令牌鉴权,登录页本质上也是对管理员令牌做一次校验后进入管理台。
现有数据结构已经为后续扩展提供了一部分基础:
api_keys 表已经预留 user_id 字段。
request_logs 与 request_billing_snapshots 已经记录 api_key_id,具备向“按密钥归属用户”聚合请求与用量的条件。
- API Key 的创建、启停、额度规则与上游授权已经具备较完整的管理能力。
但当前仍然缺少真正的用户体系,因此无法满足以下需求:
- 普通用户单独查看自己的请求记录、用量和费用信息。
- 普通用户自己管理归属于自己的 API Key。
- 管理员按用户维度启用、停用与审计账号。
Proposed Solution
建议将本需求拆成“用户体系基础能力”和“用户自助门户”两部分,并优先完成管理员激活模型。
- 新增用户实体、账号状态与角色边界,第一版至少区分
admin 与 member 两类角色。
- 管理员可以创建、激活、停用用户账号,并决定该用户是否可以登录自助门户。
- API Key 需要支持明确归属到某个用户;普通用户只能看到和操作归属于自己的 Key。
- 自助门户至少提供三类页面:个人概览、个人请求记录、个人 API Key 管理。
- 用量与费用统计优先沿用现有
request_logs 与 request_billing_snapshots 数据来源,避免再造一套并行统计逻辑。
- 管理面保留全局视图与越权审计能力,管理员可以查看全部用户、全部密钥与全部请求。
- 当前
ADMIN_TOKEN 建议继续保留为系统引导入口和紧急维护入口。
Alternatives Considered
-
第一阶段就引入第三方登录,例如 OAuth 或 OIDC。
优点是账号接入体验更完整,也更适合企业单点登录场景。代价是会同时引入身份映射、邀请流程、绑定关系、回收策略、不同提供商差异、自托管兼容性等一整组问题。
-
先做管理员激活的本地账号体系,再为未来的第三方登录预留扩展接口。
优点是范围更可控,适合当前以自托管为主的部署方式,也便于先把“用户归属、权限边界、审计记录、密钥所有权”这些核心问题做扎实。
-
继续沿用单一管理员令牌,不引入用户体系。
这种方式实现最简单,但无法满足用户自助查看与自助管理密钥的需求。
当前更适合先采用第二种方案。第三方登录更适合放在用户生命周期、权限模型和邀请激活机制稳定之后,再作为第二阶段扩展能力引入。
Acceptance Criteria
- 系统存在明确的用户实体、账号状态与角色边界。
- 管理员可以创建、激活、停用用户,并为用户分配或回收 API Key 所有权。
- 普通用户登录后只能查看自己的用量信息、请求记录与 API Key,无法访问全局管理数据。
- 普通用户可以在授权范围内自助创建、更新、停用和删除自己的 API Key。
- 现有请求日志与计费数据按用户聚合时复用现有事实表,不引入口径不一致的新统计来源。
- 第三方登录是否启用被明确设为后续可扩展项,而不是与第一阶段基础用户体系捆绑交付。
Use Case
- 作为管理员,希望能够为团队成员创建账号并决定是否激活,以便把全局管理权限和普通使用权限分开。
- 作为普通用户,希望登录后只看到自己的请求记录、自己的用量统计和自己的 API Key。
- 作为维护者,希望后续可以在不推翻用户模型的前提下,再接入 OAuth 或 OIDC。
Priority Suggestion
Medium - Would significantly improve experience
Problem Statement
当前管理面仍然是单一
ADMIN_TOKEN登录模型。/api/admin/*全部依赖管理员令牌鉴权,登录页本质上也是对管理员令牌做一次校验后进入管理台。现有数据结构已经为后续扩展提供了一部分基础:
api_keys表已经预留user_id字段。request_logs与request_billing_snapshots已经记录api_key_id,具备向“按密钥归属用户”聚合请求与用量的条件。但当前仍然缺少真正的用户体系,因此无法满足以下需求:
Proposed Solution
建议将本需求拆成“用户体系基础能力”和“用户自助门户”两部分,并优先完成管理员激活模型。
admin与member两类角色。request_logs与request_billing_snapshots数据来源,避免再造一套并行统计逻辑。ADMIN_TOKEN建议继续保留为系统引导入口和紧急维护入口。Alternatives Considered
第一阶段就引入第三方登录,例如 OAuth 或 OIDC。
优点是账号接入体验更完整,也更适合企业单点登录场景。代价是会同时引入身份映射、邀请流程、绑定关系、回收策略、不同提供商差异、自托管兼容性等一整组问题。
先做管理员激活的本地账号体系,再为未来的第三方登录预留扩展接口。
优点是范围更可控,适合当前以自托管为主的部署方式,也便于先把“用户归属、权限边界、审计记录、密钥所有权”这些核心问题做扎实。
继续沿用单一管理员令牌,不引入用户体系。
这种方式实现最简单,但无法满足用户自助查看与自助管理密钥的需求。
当前更适合先采用第二种方案。第三方登录更适合放在用户生命周期、权限模型和邀请激活机制稳定之后,再作为第二阶段扩展能力引入。
Acceptance Criteria
Use Case
Priority Suggestion
Medium - Would significantly improve experience