跳到主要内容

[草稿] 认证、菜单与权限后端说明

在 Nebula 里，nebula-auth 不只是登录模块，它还是前端工作台的结构来源。前端能不能登录、左侧菜单怎么渲染、按钮该不该显示，本质上都依赖这个模块的输出。

这个模块解决什么问题​

nebula-auth 当前已经覆盖：

  • 注册、登录、刷新令牌、退出登录
  • 当前用户查询
  • 用户、角色、权限管理
  • 组织、菜单、按钮管理
  • OAuth2 客户端和账号绑定管理

这意味着它同时承担了认证中心和平台权限中心的角色。

为什么它对前端特别重要​

对 nebula-portal 来说，最关键的不是“有个登录接口”，而是下面这组协作事实：

  • 登录结果里要能恢复当前用户会话
  • 权限码要能被 usePermission 和 NePermission 使用
  • 菜单树要能参与动态路由构建
  • 按钮权限要能决定页面动作是否显示

也就是说，前端 Shell 的很多平台能力，其实都建立在 nebula-auth 的领域模型之上。

三种接入方式怎么选​

单体项目​

依赖 nebula-auth-local，适合和 nebula-app-starter 或现有单体工程一起使用。

认证中心独立部署​

启动 nebula-auth-service，适合把认证和权限能力单独抽出来。

其他服务远程调用​

依赖 nebula-auth-remote，适合微服务消费者场景。

联调时建议优先确认什么​

如果前后端刚开始对接，建议先确认四件事：

  1. 登录接口能否返回稳定的会话结构
  2. 当前用户接口能否拿到用户和权限信息
  3. 菜单接口返回的数据是否足够驱动前端导航
  4. 按钮权限码是否与前端页面中的 code 保持一致

这四件事稳定以后，前端 Shell 的大多数主链路才能稳定运行。