Firebase安全规则配置求助：文档权限与订阅集合读写设置

嘿，我帮你搞定这个Firebase安全规则的问题！看你说配置后一直提示权限不足，结合你的两个需求，我给你一套完整的规则，还会把关键细节讲清楚，帮你避开那些容易踩的坑。

先把你的需求明确下来，避免规则跑偏：

• 需求1：只有订阅文档的创建者（所有者）能读取该文档
• 需求2：登录用户可以列出自己名下所有的订阅文档，还能编辑自己的文档，同时要加一些基础的验证规则

直接上可复用的规则代码，你可以直接复制到Firebase控制台的Firestore规则里：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 针对subscriptions集合的规则
    match /subscriptions/{subscriptionId} {
      // 读取规则：仅文档所有者可读取
      allow read: if request.auth != null && resource.data.owner == request.auth.uid;
      
      // 创建规则：登录用户才能创建，且必须把owner设为自己的UID，同时加额外验证
      allow create: if request.auth != null && 
        // 强制创建时owner必须是当前登录用户，防止篡改
        request.resource.data.owner == request.auth.uid &&
        // 示例1：订阅名称不能为空字符串
        request.resource.data.name is string && request.resource.data.name.trim() != "" &&
        // 示例2：如果有有效期字段，必须是未来的时间
        request.resource.data.expiryTime is timestamp && request.resource.data.expiryTime > request.time;
      
      // 更新规则：仅所有者可更新，且不能修改owner字段，同时验证更新内容
      allow update: if request.auth != null && 
        resource.data.owner == request.auth.uid &&
        // 禁止修改owner字段，防止把订阅转给别人（如果需要转让可以去掉这条）
        !request.resource.data.keys().hasAny(["owner"]) &&
        // 示例：更新后的名称依然不能为空
        request.resource.data.name is string && request.resource.data.name.trim() != "";
      
      // 删除规则：仅所有者可删除自己的订阅
      allow delete: if request.auth != null && resource.data.owner == request.auth.uid;
    }
  }
}

这些细节是你之前可能忽略的，也是导致权限不足的常见原因：

• 文档结构要求：每个subscriptions文档必须有owner字段，值为创建该文档的用户UID（创建规则已经强制要求了，所以前端创建时只要传对就行）
• 查询必须带过滤条件：前端查询订阅列表时，一定要加where("owner", "==", 当前用户UID)的条件！Firebase的安全规则是“查询必须能保证返回的所有文档都符合规则”，如果不带这个条件，查询可能返回其他用户的文档，所以会直接被拒绝，提示权限不足。
• 额外验证可自定义：我在规则里加了几个示例验证（比如名称非空、有效期为未来），你可以根据自己的业务需求修改，比如验证订阅金额必须是正数、状态只能是active/inactive这些枚举值等。
• 权限不足排查步骤：如果还是报错，先检查这几点：
  • 用户是否真的登录了（规则里要求request.auth != null，未登录的话所有操作都会被拒绝）
  • 文档的owner字段是否准确设置为当前用户的UID（可以去Firebase控制台的Firestore里查看文档内容）
  • 更新时是不是不小心修改了owner字段（规则里禁止了这个操作）
  • 查询有没有带owner的过滤条件

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