新增权限
StackRivet 默认拒绝:受保护端点除非有权限放行否则拒绝,且每个受保护端点都必须声明权限(否则架构测试会让构建失败)。经验法则是先在 manifest 声明权限,再给代码加注解。
<module>:<resource>:<action># 例如 customer:customer:create权限有类型:api(服务端端点)、button(UI 操作)、menu(导航项)。
1. 在模块 manifest 声明
Section titled “1. 在模块 manifest 声明”把权限(若是新导航再加一个菜单项)加到模块 manifest:
{ "permissions": [ { "code": "customer:customer:create", "type": "button", "name": "Create customer" }, { "code": "customer:customer:list", "type": "api", "name": "List customers" } ], "menus": [ { "code": "customer:customer:list", "path": "/customer/customers", "title": "Customers", "titleZh": "客户", "parent": "customer", "sortOrder": 100 } ]}manifest 是事实源:它的权限和菜单 seed 在启动时载入系统表。
2. 在 controller 强制
Section titled “2. 在 controller 强制”用 @PreAuthorize 注解端点:
@Operation(summary = "Create customer")@PostMapping@PreAuthorize("hasAuthority('customer:customer:create')")public R<CustomerResponse> create(@Valid @RequestBody CustomerCreateRequest request) { return R.ok(customerService.create(request));}已认证但无该 authority 的用户得 403;未认证请求得 401。
3. 在 UI 上门控
Section titled “3. 在 UI 上门控”对没有该权限的用户隐藏按钮,用 StackRivet 的权限指令/组件(按钮权限)。UI 隐藏只为体验——第 2 步的服务端校验才是真正的控制。
4. 分配给角色
Section titled “4. 分配给角色”权限在角色拥有它、且用户拥有该角色之前,什么都不做。在管理端打开 系统 → 角色,编辑某角色,授予新的菜单/按钮。拥有该角色的用户下次登录时获得权限(权限在登录时解析)。
# 无该 authority → 403curl -i -H "Authorization: Bearer $TOKEN" -X POST \ http://127.0.0.1:8080/api/v1/customers# 给角色授权该权限后 → 201/200也可通过查看菜单树(GET /api/v1/menus/tree)确认 seed 已载入新条目。
保持声明与强制点同步
Section titled “保持声明与强制点同步”在 manifest 声明了权限却忘了 @PreAuthorize,会让端点失去保护——架构/安全评审会抓到。反之,注解里用了一个 manifest 没声明的权限码,则没有任何角色能被授予它。两者必须保持同步。