[Feature] Portal 管理页支持查看和撤销Open API Token的具体授权

[LinyingHong]

Is your feature request related to a problem? Please describe.

一个 Open API Token（Consumer）在 Apollo Portal 中支持授权多个 App / Namespace，这在多个项目共用一个集成 token 的场景下很常见。但目前 Portal 管理页 /open/manage.html（仅超级管理员）存在两个痛点：

1. 看不见 token 授权了哪些 App / Namespace。 列表页只显示归属 AppId、名称、允许创建应用、限流 QPS、部门、Owner，没有任何入口能查看这个 token 到底被授予了对哪些 App / Namespace 的管理权限。

当前 Consumer 列表页：只有 "Grant Permission" 和 "Delete" 两个操作，看不到已授权范围。

2. 无法撤销单条 App / Namespace 授权。 "Grant Permission" 弹窗是只增不删的；要移除某条授权，目前唯一的办法是删除整个 Consumer，这会连同 token 一起销毁，所有下游调用方都必须重新对接。

在实际运维中，一个 token 随着时间会累积很多 App 的授权，目前没有安全的方式去精细收敛权限。

Describe the solution you'd like

保留现有的 "Grant Permission" 添加流程不变，在其之上增加查看 + 撤销能力：

UI 改造

• 列表页每一行新增 "View Permissions" 按钮。
• 点击后弹出面板，列出该 token 当前持有的所有授权（App 级与 Namespace 级，Namespace 级带上 namespaceName 和 env）。
• 每一行末尾提供 "Revoke" 按钮，带二次确认。
• 修改场景通过"撤销 + 重新使用现有 Grant Permission 添加"完成，不引入独立的 edit 语义

Portal Management API 新增

1. GET /openapi/v1/consumers/{token}/authorized-apps
   返回该 Consumer 当前所有 App / Namespace 授权列表。底层的 ConsumerService#findAppIdsAuthorizedByConsumerId(long) 已存在，目前只服务于 token 持有方自查的 /openapi/v1/apps/authorized，尚未开放给管理端。
2. DELETE /openapi/v1/consumers/{token}/roles
   参数：type=AppRole|NamespaceRole、appId、可选 namespaceName、可选 env。撤销一条授权；Namespace 级撤销会同时移除对应的 ModifyNamespace 和 ReleaseNamespace 绑定。

两个新接口和 UI 入口继续沿用现有 Consumer 管理面的权限边界，通过 @unifiedPermissionValidator.isSuperAdmin() / isRootUser 限制超级管理员，并写入 ConsumerAudit。

按仓库 AGENTS.md 的契约先行要求，会先在 apolloconfig/apollo-openapi 提 spec PR，主仓再 bump apollo.openapi.spec.url 并在 PortalManagementController 实现生成的接口。

Describe alternatives you've considered

• 删除并重建整个 Consumer（当前唯一 workaround）：会丢失 token、影响所有下游、无法只收敛某一个 App。

Additional context

底层数据模型已经支持一个 token 授权多个 App：授权关系记录在 ConsumerRole (consumerId, roleId) 表中，roleId 指向该 App 的 Master+{appId} 或该 Namespace 的 ModifyNamespace+... / ReleaseNamespace+... role。缺的只是管理端的查询、撤销接口，以及 UI 展示。

[github-actions]

🤖 感谢提交这个详细的需求。

该 issue 描述了 Portal 中 Open API Token（Consumer）管理的两个痛点：

1. 无法查看已授权的 App / Namespace 列表
2. 无法撤销单条授权（仅能删除整个 Consumer）

提出的解决方案（View Permissions + Revoke 功能）思路清晰，同时遵循了仓库的契约先行流程（先在 apollo-openapi 提 spec PR）。

已添加 feature request、area/portal、area/openapi 标签，维护者会进行评估。若通过，实现时需注意：

• Portal Management API 继续采用 @PreAuthorize 保护超级管理员权限
• 撤销操作需写入 ConsumerAudit 审计
• UI 二次确认防误操作

期待后续 PR！

AI generated by Apollo Issue Triage

[nobodyiam]

这个功能目前确实不存在，需求方向可行，欢迎继续按 contract-first 流程推进。现有 bot 回复已经覆盖了总体方向，这里补充几个实现边界，避免后续 PR 返工：

1. 新增管理接口建议使用 consumerId，不要继续把完整 token 作为 URL 资源标识。例如：

   • GET /openapi/v1/consumers/{consumerId}/roles
   • DELETE /openapi/v1/consumers/{consumerId}/roles

   当前 GET /openapi/v1/consumers 已返回 consumerId。现有 {token}/assign-role 可以暂时作为兼容接口保留，但新接口不应继续扩大 token 出现在 URL 和访问日志中的范围。

2. ConsumerService#findAppIdsAuthorizedByConsumerId 只能返回 AppId 集合，不能直接支撑 Namespace、env 和授权类型明细。请先在 apollo-openapi 定义明确的响应模型，例如 type、appId、namespaceName、env，再在 ConsumerService 中根据 ConsumerRole -> Role 做映射。对于同一 Namespace 的 ModifyNamespace 和 ReleaseNamespace，UI 可以聚合为一条逻辑授权；系统级角色仍由现有列表字段展示，不需要混入该接口。

3. 撤销操作必须限定 consumerId + roleIds，并在一个事务中完成：

   • AppRole 只移除对应的 Master+{appId}；
   • NamespaceRole 同时移除同一目标的 ModifyNamespace 和 ReleaseNamespace；
   • 不要直接复用 ConsumerRoleRepository#batchDeleteByRoleIds，该方法只按 roleId 更新，会影响持有同一角色的其他 Consumer。建议新增同时带 consumerId、roleIds 和 operator 的软删除方法。

4. ConsumerAudit 用于记录 Consumer 调用 OpenAPI 的访问行为，不适合记录 Portal 管理员撤权。管理端撤权请使用 Apollo Audit，例如在 Controller 上增加 @ApolloAuditLog(type = OpType.DELETE, ...)，同时通过 ConsumerRole.DataChange_LastModifiedBy 保留操作人。

5. PR 请覆盖以下测试：

   • App、无 env Namespace、带 env Namespace 的授权列表与聚合；
   • 撤销仅影响目标 Consumer，Namespace 两条角色绑定同时撤销；
   • 普通 Portal 用户和 Consumer Token 不能调用管理接口；
   • Portal UI 的二次确认、成功/失败提示及中英文文案。

另外，本地联调不需要先发布 apollo-openapi tag，也不要为了测试修改并提交 apollo-portal/pom.xml 中的默认 URL。可以用环境变量保存本地 spec 的绝对路径，再通过 Maven property 覆盖：

export APOLLO_OPENAPI_SPEC_URL=/absolute/path/to/apollo-openapi/apollo-openapi.yaml

./mvnw -pl apollo-portal -am \
  -Dapollo.openapi.spec.url="$APOLLO_OPENAPI_SPEC_URL" \
  -DskipTests compile

这样 openapi-generator-maven-plugin 会直接读取本地 YAML，生成 PortalManagementApi 和相关模型，方便在本机同时联调 apollo-openapi 与 apollo。需要注意，环境变量本身不会被 Maven 自动映射，命令中的 -Dapollo.openapi.spec.url=... 不能省略；正式提交时，POM 默认值仍应指向已经发布的远程 tag。

OpenAPI spec PR 合并并发布后，再在 apollo 中更新 apollo.openapi.spec.url、实现生成的 PortalManagementApi 接口并补齐 UI 即可。