Firestore使用onSnapshot时多对多关系如何配置符合安全规则的访问模式

问题根因 #

你遇到的规则执行失败不是因为计算成本过高，而是Firestore安全规则的核心设计逻辑是规则不是过滤器，它只会验证你的查询是否天然满足权限约束，不会逐文档扫描校验查询结果是否合规。你当前的规则要求逐文档比对用户组和资源可访问组，针对集合级的查询（包括onSnapshot监听）规则无法直接验证查询的合法性，因此直接拒绝请求，这也是为什么单文档get请求可以正常生效的原因。

适配方案 #

方案1：保留用户多归属组能力

利用Firestore规则的request.query校验能力，直接验证你查询时传入的array-contains-any参数与当前登录用户的所属组完全一致，无需逐文档校验：

修改后的安全规则

match /resources/{resourceId} {
  allow read: if request.auth != null
    // 校验查询确实使用了accessibleBy的array-contains-any条件
    && "array-contains-any" in request.query.where["accessibleBy"]
    // 校验查询传入的组列表完全等于当前用户的所属组
    && request.query.where["accessibleBy"]["array-contains-any"] == get(/databases/$(database)/documents/users/$(request.auth.uid)).data.groups;
}

配套查询逻辑和原实现一致：

db.collection('/resources').where("accessibleBy", "array-contains-any", [...当前用户的groups数组])

注意：该方案受Firestore array-contains-any 最多支持10个参数的限制，如果用户所属组超过10个无法使用。

方案2：接受用户单归属组约束（更稳定高效）

如果可以限制每个用户仅属于一个用户组，推荐使用自定义声明的方案，性能最好也最容易维护：

1. 编写简单的Cloud Function，在给用户分配用户组时，将用户的组ID写入Firebase Auth的自定义声明中：

// 云函数示例片段
await admin.auth().setCustomUserClaims(userId, {
  groupId: 分配的用户组ID
})

2. 修改安全规则，无需额外读请求即可完成校验：

match /resources/{resourceId} {
  allow read: if request.auth != null
    && resource.data.accessibleBy.includes(request.auth.token.groupId);
}

3. 配套查询逻辑修改为：

// 从用户token中拿到groupId即可
db.collection('/resources').where("accessibleBy", "array-contains", userGroupId)

该方案没有参数数量限制，规则校验无额外读成本，完全支持onSnapshot实时监听，也保留了资源可以共享给多个用户组的能力，是目前最优的适配方案。

内容的提问来源于stack exchange，提问作者Ric Barnes