Skip to content

权限体系 ​

Java 权限分为菜单、按钮、接口和数据范围。页面可见只说明获得导航能力,不代表有权限读取或修改全部数据。

四层分别配置 ​

层次控制对象核对入口
菜单页面与导航menu、角色菜单关系、前端路由映射
按钮页面内动作菜单按钮标记、前端 meta.authList 与指令
API实际 HTTP 操作RequireApiPermission、接口目录、角色显式授权
数据范围可见、可更新或可删除的资源集合DataScopeResolver 及所属域 SQL/Service

接口码与按钮标记不是同一种编码。例如接口可能为 system:menu:create,按钮标记为 add,不能从其中一个自动推导另一个。

内置角色 ​

角色用途
R_SUPER超级管理员,首次分配给 admin
R_USER注册与后台新建用户的默认角色,具有明确的基础授权
R_DEMO_ADMIN演示管理角色预设,不创建默认演示账号

超级管理员仅按启用的 R_SUPER 识别,用户名 admin 或自定义名称不能代替角色。多角色按权限并集计算;为公开演示账号配置角色时,不要叠加超级角色扩大权限。

R_DEMO_ADMIN 不是全站只读,允许部分业务写操作。公开演示前按实际需求检查资金、文件、用户管理、任务执行及配置修改权限。

给角色授权的完整步骤 ​

  1. 确认菜单引用的前端 component 与共享前端实际组件一致。
  2. 分配需要的菜单和按钮。
  3. 按实际接口配置 API 权限;列表、详情、选项、附件等依赖接口也要核对。
  4. 在支持数据范围的资源上配置查看、更新、删除范围。
  5. 使用目标普通账号验证允许和拒绝场景,不只使用超级管理员测试。

当前用户资料、退出、会话与密码维护也有对应 account:* 授权。自定义角色如果遗漏,会表现为登录成功但初始化或个人操作失败。

示例:给“参数维护员”开放查询与编辑 ​

在管理端创建角色并绑定一个普通用户,分配参数设置菜单和需要的按钮。接口授权至少包含 system:param:list、system:param:detail、system:param:update,再按页面请求补齐依赖接口与基础 account:* 权限。

若不允许新增或删除,不分配对应 system:param:create / system:param:delete。为支持范围控制的操作设置合适的数据权限后,以该用户验证:列表可读、允许范围内可编辑、越权操作被拒绝。不要给这个测试用户同时绑定 R_SUPER,否则无法验证角色限制。

菜单按钮标记与上述 API 权限码分别配置,菜单可见不会自动授予接口访问权。

新接口的 Java 入口 ​

Controller 用 @RequireApiPermission(...) 声明接口码,ApiPermissionInterceptor 经授权服务检查有效角色。前端的 apiPermissions 快照用于体验层预校验,不替代后端实时授权。

新增能力还需维护接口目录、菜单/按钮、目标角色绑定与超级管理员授权。已有客户库通过新增 Flyway 迁移调整,不编辑旧初始化脚本,也不自动提升所有自定义角色。

数据范围边界 ​

审批定义使用 workflow:definition,实例按本人、参与者、抄送与管理范围判定;缺失策略时拒绝。附件还要检查实例关联与字段可见性。

商城当前没有租户或部门级隔离。其他资源支持数据权限,也不能推定商城自动获得相同过滤。超级管理员具有管理可见范围,不意味着可替代当前审批人处理任务。

排查菜单或按钮异常 ​

依次检查当前用户信息、菜单响应、有效角色、按钮标记、接口码与数据范围。授权变更后核对缓存失效与新请求结果,不通过前端写死放行修复。

源码入口:access/api、access/security、access/service、menu 和各域 security;随包深入说明为 docs/guides/permission-contract.md。

根据 MIT 许可证发布