admin-api-id-test/api/v1/admin/users 即返回真实用户数据(含手机号)。
谁知道域名就能在公网读全量用户 PII、调写接口(发券 / 改配置 / 提现审批代理)。
架构上 admin 前端是「一套、按 env 切换按钮选国家后端」。那个按钮只是前端选择器、不是安全边界——真正的门必须落在每个国家的 admin 后端各自鉴权。
运营用飞书账号登录(团队已在用飞书,集中管人 + 可上 MFA),后端签发 JWT,每个 admin 接口校验身份 + RBAC 权限,并校验「该运营能否操作这个国家 / 这个环境」。
| 层 | 做什么 |
|---|---|
| 登录 | 飞书 OAuth/OIDC 授权登录,拿到运营的飞书身份 |
| 会话 | 后端校验飞书 code → 查角色 → 签发 JWT(短期)+ 刷新机制 |
| 鉴权 | 每个 admin 接口校验 JWT;过滤器/拦截器统一拦,而非逐接口写 |
| 授权(RBAC) | 角色 → 权限:查看 / 改价 / 发券 / 提现审批 …,并绑定可操作的国家 + 环境 |
| 多国家 | 每条 admin-api-{country}-{env} 各自验,前端按钮切了也得后端放行 |
sequenceDiagram
autonumber
participant O as 运营(浏览器)
participant FE as admin 前端
participant BE as admin 后端
participant FS as 飞书 OAuth
O->>FE: 打开后台
FE->>FS: 跳转飞书授权
O->>FS: 飞书账号确认 (可 MFA)
FS-->>FE: 回调 code
FE->>BE: 用 code 登录
BE->>FS: 校验 code · 拉飞书身份
BE->>BE: 查角色/权限(RBAC) · 签发 JWT
BE-->>FE: 返回 JWT
Note over FE,BE: 之后每个请求头带 Authorization: Bearer JWT
FE->>BE: 调 admin 接口(带 JWT)
BE->>BE: 校验 JWT + 能否操作此国家/环境/动作
BE-->>FE: 放行 / 401·403