权限体系
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 不是全站只读,允许部分业务写操作。公开演示前按实际需求检查资金、文件、用户管理、任务执行及配置修改权限。
给角色授权的完整步骤
- 确认菜单引用的前端
component与共享前端实际组件一致。 - 分配需要的菜单和按钮。
- 按实际接口配置 API 权限;列表、详情、选项、附件等依赖接口也要核对。
- 在支持数据范围的资源上配置查看、更新、删除范围。
- 使用目标普通账号验证允许和拒绝场景,不只使用超级管理员测试。
当前用户资料、退出、会话与密码维护也有对应 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。
