ZenStack 访问策略中 check() 与 future() 函数的交互问题解析

在权限控制系统的设计中，ZenStack 提供了一套灵活的访问策略机制。本文将深入分析一个在 v2.4.1 版本中发现的访问策略交互问题，特别是 check() 函数与 future() 函数同时使用时产生的意外行为。

问题背景

在 ZenStack 的模型访问策略中，开发者可以使用 check() 函数将权限检查委托给关联模型，同时也可以使用 future() 函数来验证更新后的字段值。然而，当这两种机制同时使用时，会出现权限检查失效的情况。

考虑以下典型场景：

model Post {
    id Int @id
    title String
    description String
    author User @relation(fields: [authorId], references: [id])
    authorId Int

    // 将权限检查委托给作者
    @@allow('all', check(author))

    // 检查更新后的标题是否为"hello"
    @@allow('update', future().title == 'hello')
}

在这个例子中，即使关联的 User 模型具有更新权限，当尝试更新 Post 的 description 字段时，操作也会失败。

技术原理分析

这个问题源于 ZenStack 内部对 future() 函数的特殊处理机制：

1. 策略分类机制：ZenStack 内部将涉及 future() 的规则归类为"post-update"策略类型。如果没有使用 future() 函数，则"post-update"检查默认通过。

2. 委托机制：check(author) 调用会将所有策略检查（包括"post-update"）委托给 author 模型。由于 User 模型没有定义任何 future() 规则，"post-update"检查总是会通过。

3. 策略优先级：当同时存在普通策略和"post-update"策略时，系统会优先执行"post-update"检查，导致委托的权限检查被覆盖。

解决方案

ZenStack 团队在 v2.5.0 版本中修复了这个问题，主要改动是：

1. 修改委托行为：不再通过 check() 调用委托"post-update"策略检查。
2. 策略执行顺序优化：确保委托策略和本地策略能够正确组合执行。

最佳实践建议

在使用 ZenStack 的访问策略时，建议开发者：

1. 尽量避免在同一模型上混用 check() 委托和 future() 检查
2. 如果必须同时使用，考虑将 future() 检查也移到被委托的模型中
3. 对于复杂的权限逻辑，可以考虑使用自定义函数或组合多个策略表达式

总结

权限控制是应用安全的核心环节，理解框架底层的行为机制对于设计健壮的访问策略至关重要。ZenStack 通过这次修复，使得 check() 和 future() 的交互行为更加符合开发者的直觉预期，为构建安全的应用程序提供了更可靠的保障。