Recipe：Column-based Access

• 官方来源：examples/recipes/column-based-access
• 核对日期：2026-05-22

这个示例解决什么问题

如何让用户只能看到与自己有关联的供应商信息，而不是任意访问关联表里的敏感字段。

官方示例的核心做法

示例定义了：

• Products cube
• Suppliers cube
• Products 通过 supplier_id 关联 Suppliers

然后在 queryRewrite 中判断：

• 如果查询涉及 Products；
• 就要求 securityContext.email 存在；
• 并自动追加 Suppliers.email = securityContext.email 的过滤条件。

这说明了什么

1. “列级访问”很多时候其实和 join 条件绑定

不是单纯隐藏字段，而是：

• 允许走到某个关联实体；
• 但只能看到与当前用户身份匹配的数据。

2. 关联路径往往是权限治理的关键点

如果没有语义层，应用团队很容易漏掉这种跨表限制。

3. Query rewrite 可以利用查询本身引用了哪些成员来决定是否加限制

示例里会先扫描 query 中涉及的 cube 名称，再决定是否加过滤。

适合迁移的业务场景

• 供应商只能看自己的产品；
• 渠道商只能看属于自己的客户线索；
• 门店负责人只能看自己门店相关商品或库存。

实战建议

• 不要只控制前端显示，要控制查询本身；
• 对跨 cube 查询，尤其要检查 join 后是否越权；
• 如果字段高度敏感，考虑 view 暴露最小集合。

和教程哪章搭配最好

• 核心概念
• 权限治理

一句话总结

这个 recipe 的核心价值是：展示权限治理不仅是“能不能看这列”，更是“通过哪条 join 路径、在什么身份约束下看这列”。