Recipe：Role-based Access
- 官方来源：
examples/recipes/role-based-access - 核对日期：2026-05-22
这个示例解决什么问题
如何根据不同角色，对同一查询自动追加不同过滤条件。
官方示例的核心做法
示例在 cube.js 中使用 queryRewrite：
- 如果
securityContext.role == manager，自动限制为shipped和completed； - 如果
securityContext.role == operator，自动限制为processing。
底层 Orders cube 很简单，真正的权限逻辑不写在模型成员里，而写在请求改写阶段。
这说明了什么
1. 权限不一定总是写成静态 access policy
有些场景下，queryRewrite 是非常直接、非常工程化的做法。
2. 同一个前端查询，可以因角色不同而命中不同数据范围
这对：
- 运营后台
- 客服系统
- 订单处理系统
都很常见。
3. Security Context 是整个权限体系的输入
没有稳定的 securityContext，这类模式就无法成立。
适合迁移的业务场景
- 仓库经理只看已发货 / 已完成订单；
- 一线操作员只看处理中订单；
- 财务只看已结算记录；
- 区域经理只看本区域数据。
实战建议
优点
- 简单直接；
- 易于按角色快速扩展；
- 非常适合入门理解 Cube 权限链路。
注意点
- 角色越来越多时，逻辑会膨胀；
- 更复杂场景可再考虑 access policies、views、row-level security 分层；
- 需要统一认证与 token 载荷设计。
和教程哪章搭配最好
一句话总结
这个 recipe 的核心价值是：展示如何把角色差异前置到查询改写阶段，让同一语义接口在不同角色下自动收敛到不同数据范围。