跳转到内容

新增权限

StackRivet 默认拒绝:受保护端点除非有权限放行否则拒绝,且每个受保护端点都必须声明权限(否则架构测试会让构建失败)。经验法则是先在 manifest 声明权限,再给代码加注解

<module>:<resource>:<action>
# 例如 customer:customer:create

权限有类型api(服务端端点)、button(UI 操作)、menu(导航项)。

把权限(若是新导航再加一个菜单项)加到模块 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 在启动时载入系统表。

@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

对没有该权限的用户隐藏按钮,用 StackRivet 的权限指令/组件(按钮权限)。UI 隐藏只为体验——第 2 步的服务端校验才是真正的控制。

权限在角色拥有它、且用户拥有该角色之前,什么都不做。在管理端打开 系统 → 角色,编辑某角色,授予新的菜单/按钮。拥有该角色的用户下次登录时获得权限(权限在登录时解析)。

Terminal window
# 无该 authority → 403
curl -i -H "Authorization: Bearer $TOKEN" -X POST \
http://127.0.0.1:8080/api/v1/customers
# 给角色授权该权限后 → 201/200

也可通过查看菜单树(GET /api/v1/menus/tree)确认 seed 已载入新条目。

在 manifest 声明了权限却忘了 @PreAuthorize,会让端点失去保护——架构/安全评审会抓到。反之,注解里用了一个 manifest 没声明的权限码,则没有任何角色能被授予它。两者必须保持同步。