Firestore如何验证数组值与动态映射字段？用户引用验证问询

Great question! This is a super common hurdle when moving from Firebase Realtime Database to Firestore—their security rule systems operate very differently, and that handy dynamic field iteration trick from Realtime DB doesn’t translate directly. Let’s break down how to solve this properly.

First: Refactor Your Data Structure (Critical Step) #

Firestore security rules can’t iterate over dynamic field keys (like using user IDs as field names in your original members structure). So we need to adjust how we store member data to work with Firestore’s capabilities.

Instead of this structure:

"members": { "firstUserId" : true, "secondUserId" : true, "thirdUserId" : true }

Switch to an array of user IDs—this is the most Firestore-friendly approach:

"members": ["firstUserId", "secondUserId", "thirdUserId"]

If you might need to store extra metadata per member later (like roles), you can use an array of objects instead:

"members": [
  { "userId": "firstUserId", "role": "member" },
  { "userId": "secondUserId", "role": "admin" }
]

Validate Arrays with Firestore Rules #

Once you’ve switched to an array, you can use Firestore’s every() rule function to check that every user ID in the array corresponds to an existing document in your users collection.

For Simple User ID Arrays #

Here’s a rule that validates a group document (or any document with a members array):

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Validate group documents with a members array
    match /groups/{groupId} {
      allow write: if request.resource.data.members.every(userId => 
        exists(/databases/$(database)/documents/users/$(userId))
      );
    }

    // Basic read access for users collection (adjust to your auth rules)
    match /users/{userId} {
      allow read: if true;
    }
  }
}

This rule ensures that every entry in members links to a real user in the users collection.

For Arrays of Objects (With Metadata) #

If you’re using objects in the array, just target the userId field within each object:

allow write: if request.resource.data.members.every(member => 
  exists(/databases/$(database)/documents/users/$(member.userId))
);

What If You Can’t Refactor the Dynamic Field Structure? #

If you absolutely need to keep the original "user ID as field key" setup (e.g., for legacy code), Firestore rules can’t validate all those dynamic fields directly. Your options here are:

• Use a Cloud Function trigger: Write a Cloud Function that runs on document create/update. It can loop through each field in members, check if the user exists, and either delete the invalid document or flag it for review.
• Combine client-side validation with basic rule checks: Validate all user IDs on the client before writing to Firestore, and add rules to ensure the field values are valid (even if it can’t check user existence):

  match /groups/{groupId} {
    allow write: if request.resource.data.members is map && 
      request.resource.data.members.values().every(val => val == true);
  }
  

  Note: This only checks that the values are true booleans—you’ll still need client-side or Cloud Function logic to verify user existence.

Quick Recap #

• Firestore doesn’t support iterating over dynamic field keys, so arrays are the cleanest rule-based solution.
• Use every() in rules to validate each array element against the users collection.
• For legacy structures, pair client-side checks with Cloud Functions to enforce user existence.

内容的提问来源于stack exchange，提问作者Paolo 'Callo' Caleffi