Firestore安全规则配置：基于UID允许访问所有子集合

我来帮你配置符合需求的Firestore安全规则，核心目标是让已认证用户只能访问属于自己的Users文档及其下所有子集合（比如Towers），下面分两种场景给出最优方案：

场景1：用户文档ID与playerUid一致（推荐） #

如果你的Users集合中文档的ID直接等于用户的认证UID（即playerUid字段值和文档ID相同），可以用这个更简洁高效的规则：

service cloud.firestore {
  match /databases/{database}/documents {
    // 基础规则：所有操作要求用户已认证
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }

    // 匹配Users集合下的单个用户文档
    match /users/{playerUid} {
      // 允许用户读写自己的文档
      allow read, create, update, delete: if request.auth.uid == playerUid;

      // 匹配该用户文档下的所有子集合（包括Towers）
      match /{subcollection=**} {
        // 允许用户读写自己文档下的所有子集合内容
        allow read, write: if request.auth.uid == playerUid;
      }
    }
  }
}

规则解释： #

• 顶层的通配规则确保所有未被更精确规则覆盖的路径，都要求用户已认证。
• /users/{playerUid}路径直接绑定用户UID，通过request.auth.uid == playerUid确保只有文档所有者能操作自己的文档。
• /{subcollection=**}是递归通配符，会匹配该用户文档下的所有子集合（不管嵌套多少层），同样通过UID匹配限制访问权限。

场景2：用户文档ID与playerUid不同 #

如果你的Users集合中文档ID和playerUid字段值不一致（比如文档ID是自定义生成的，playerUid存储用户认证UID），需要通过get()函数验证父文档的权限：

service cloud.firestore {
  match /databases/{database}/documents {
    // 基础规则：所有操作要求用户已认证
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }

    // 匹配Users集合下的单个用户文档
    match /users/{userDocId} {
      // 创建文档时：确保playerUid等于当前用户UID
      allow create: if request.auth.uid != null && request.resource.data.playerUid == request.auth.uid;
      // 读写删文档时：验证文档的playerUid等于当前用户UID
      allow read, update, delete: if request.auth.uid != null && resource.data.playerUid == request.auth.uid;

      // 匹配该用户文档下的所有子集合
      match /{subcollection=**} {
        // 通过get()获取父用户文档，验证其playerUid等于当前用户UID
        allow read, write: if request.auth.uid != null && 
          get(/databases/$(database)/documents/users/$(userDocId)).data.playerUid == request.auth.uid;
      }
    }
  }
}

规则解释： #

• 创建文档时，强制要求request.resource.data.playerUid（即将写入的playerUid值）等于当前用户UID，避免用户创建不属于自己的文档。
• 对于子集合的访问，通过get()函数获取父级用户文档，检查其playerUid字段是否匹配当前用户UID，确保用户只能访问自己文档下的子集合内容。

注意事项： #

• Firestore规则是优先匹配更具体的路径，所以子集合的规则会覆盖顶层的通配规则。
• 如果使用场景2的规则，注意get()函数会消耗少量规则评估资源，但对于大多数应用场景来说完全可以忽略。

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