Skip to content

设计并引入多用户、自助用量查询与自助密钥管理 #109

@g1331

Description

@g1331

Problem Statement

当前管理面仍然是单一 ADMIN_TOKEN 登录模型。/api/admin/* 全部依赖管理员令牌鉴权,登录页本质上也是对管理员令牌做一次校验后进入管理台。

现有数据结构已经为后续扩展提供了一部分基础:

  1. api_keys 表已经预留 user_id 字段。
  2. request_logsrequest_billing_snapshots 已经记录 api_key_id,具备向“按密钥归属用户”聚合请求与用量的条件。
  3. API Key 的创建、启停、额度规则与上游授权已经具备较完整的管理能力。

但当前仍然缺少真正的用户体系,因此无法满足以下需求:

  1. 普通用户单独查看自己的请求记录、用量和费用信息。
  2. 普通用户自己管理归属于自己的 API Key。
  3. 管理员按用户维度启用、停用与审计账号。

Proposed Solution

建议将本需求拆成“用户体系基础能力”和“用户自助门户”两部分,并优先完成管理员激活模型。

  1. 新增用户实体、账号状态与角色边界,第一版至少区分 adminmember 两类角色。
  2. 管理员可以创建、激活、停用用户账号,并决定该用户是否可以登录自助门户。
  3. API Key 需要支持明确归属到某个用户;普通用户只能看到和操作归属于自己的 Key。
  4. 自助门户至少提供三类页面:个人概览、个人请求记录、个人 API Key 管理。
  5. 用量与费用统计优先沿用现有 request_logsrequest_billing_snapshots 数据来源,避免再造一套并行统计逻辑。
  6. 管理面保留全局视图与越权审计能力,管理员可以查看全部用户、全部密钥与全部请求。
  7. 当前 ADMIN_TOKEN 建议继续保留为系统引导入口和紧急维护入口。

Alternatives Considered

  1. 第一阶段就引入第三方登录,例如 OAuth 或 OIDC。
    优点是账号接入体验更完整,也更适合企业单点登录场景。代价是会同时引入身份映射、邀请流程、绑定关系、回收策略、不同提供商差异、自托管兼容性等一整组问题。

  2. 先做管理员激活的本地账号体系,再为未来的第三方登录预留扩展接口。
    优点是范围更可控,适合当前以自托管为主的部署方式,也便于先把“用户归属、权限边界、审计记录、密钥所有权”这些核心问题做扎实。

  3. 继续沿用单一管理员令牌,不引入用户体系。
    这种方式实现最简单,但无法满足用户自助查看与自助管理密钥的需求。

当前更适合先采用第二种方案。第三方登录更适合放在用户生命周期、权限模型和邀请激活机制稳定之后,再作为第二阶段扩展能力引入。

Acceptance Criteria

  1. 系统存在明确的用户实体、账号状态与角色边界。
  2. 管理员可以创建、激活、停用用户,并为用户分配或回收 API Key 所有权。
  3. 普通用户登录后只能查看自己的用量信息、请求记录与 API Key,无法访问全局管理数据。
  4. 普通用户可以在授权范围内自助创建、更新、停用和删除自己的 API Key。
  5. 现有请求日志与计费数据按用户聚合时复用现有事实表,不引入口径不一致的新统计来源。
  6. 第三方登录是否启用被明确设为后续可扩展项,而不是与第一阶段基础用户体系捆绑交付。

Use Case

  1. 作为管理员,希望能够为团队成员创建账号并决定是否激活,以便把全局管理权限和普通使用权限分开。
  2. 作为普通用户,希望登录后只看到自己的请求记录、自己的用量统计和自己的 API Key。
  3. 作为维护者,希望后续可以在不推翻用户模型的前提下,再接入 OAuth 或 OIDC。

Priority Suggestion

Medium - Would significantly improve experience

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature新功能请求

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions