跳到主要内容

[草稿] Nebula 权限模型说明

在 Nebula 中，权限能力由 nebula-auth 模块承载。为了避免把 IAM 讲成一套脱离代码的抽象模型，这篇文档只描述当前仓库中可以明确确认的权限对象、协作关系和前后端使用方式。

权限模型里有哪些核心对象​

从当前 nebula-auth 模块和接口结构看，权限模型至少围绕这些对象展开：

  • 用户（User）
  • 角色（Role）
  • 组织（Org）
  • 菜单（Menu）
  • 按钮（Button）
  • 权限（Permission）

这些对象共同组成 Nebula 的平台访问控制基础。

可以怎么理解它们之间的关系​

主体​

主体是“谁拥有权限”，当前主要包括：

  • 用户
  • 角色
  • 组织

资源​

资源是“权限作用到什么东西上”，当前最直接对应：

  • 菜单
  • 按钮

这也是为什么 nebula-auth 同时提供了菜单管理、按钮管理和权限管理接口。它不是三块互不相关的功能，而是一个统一权限模型的不同观察面。

对前端最有意义的理解方式​

对 nebula-portal 而言，权限模型最重要的不是数据库表怎么命名，而是下面这条协作链：

  1. 用户登录后获得当前会话
  2. 前端拿到当前用户和权限信息
  3. 菜单数据参与动态导航和路由装载
  4. 按钮权限码控制页面动作显示与否

因此，Nebula 权限模型既影响后端授权判断，也直接影响前端页面结构。

当前已能确认的接口分组​

从 nebula-auth-local 当前控制器可以确认这些接口分组：

  • /api/auth/users/*
  • /api/auth/roles/*
  • /api/auth/permissions/*
  • /api/auth/orgs/*
  • /api/auth/menus/*
  • /api/auth/buttons/*

它们共同构成了权限域最核心的操作入口。

为什么菜单和按钮要放进权限模型​

在普通业务系统里，菜单和按钮有时只是“页面元素”。但在 Nebula 这样的中台里，它们更像平台资源：

  • 菜单决定用户能否进入某个页面或模块
  • 按钮决定用户在页面里能否执行某个动作

所以把菜单、按钮纳入同一套权限域，是符合中台工作台场景的。

推荐的协作理解​

后端视角​

后端负责维护用户、角色、组织、菜单、按钮和权限配置，并在认证与授权链路中提供统一结果。

前端视角​

前端负责消费这些结果，用于：

  • 登录后恢复当前用户状态
  • 构建动态菜单和动态路由
  • 控制按钮与操作区显隐

联调视角​

前后端最需要对齐的三类信息是：

  • 当前用户会话结构
  • 菜单树与组件 key 对应关系
  • 按钮权限 code 的命名与使用方式

只要这三类信息稳定，Nebula 的权限协作链路就会顺畅很多。

这篇文档故意不展开什么​

这篇文档不再继续保留旧版里那种脱离现有仓库的 nebula-ima-* 模块命名，也不强行给出当前仓库里没有明确验证的表结构细节。这样做的目的是让 IAM 文档和实际代码保持一致，而不是让新人读完后再去怀疑项目里为什么找不到对应模块。