Firestore安全规则：动态字段结构校验策略

本文探讨了在Firestore中对动态命名（如UUID）的文档字段进行结构校验的挑战与解决方案。由于Firestore安全规则无法直接迭代未知字段，我们提出了一种“指针”字段策略：在写入新动态字段时，同时将该字段的名称写入一个已知字段。安全规则即可通过读取该已知字段来获取动态字段名，进而对其内容进行精确的结构校验，确保数据一致性。

动态字段校验的挑战

在firestore文档中，有时我们需要存储一系列结构相似但字段名是动态生成的（例如，使用uuid作为键）的映射数据。考虑以下文档结构：

{   "documentId": {     "6e219b89-98fb-44cd-b6ad-e22888b6fb2f": {       "name": "Harry",       "age": 20     },     "345c635a-11cb-4165-86ef-50be50794532": {       "name": "Mary",       "age": 30     }   } }

当客户端代码向此类文档添加一个新的动态字段时，例如：

import { doc, updateDoc } from "firebase/firestore"; import { db } from "./firebaseConfig"; // 假设这是你的Firestore实例  const docRef = doc(db, "yourCollection", "documentId");  await updateDoc(docRef, {     [crypto.randomUUID()]: { // 动态生成字段名             name: 'Sally',             age: 24,     } });

我们面临的挑战是，如何在Firestore安全规则中验证这个新添加的动态字段（其键是随机UUID）是否符合预期的结构，例如 name 必须是字符串，age 必须是数字。

Firestore安全规则的一个核心限制是它们无法迭代未知字段或使用通配符来匹配字段名。这意味着我们不能直接编写类似 request.Resource.data.*.name is String 这样的规则来校验所有动态子字段。如果字段名已知，我们可以轻松地写出 request.resource.data.knownField.name is string，但对于动态生成的UUID，这种方法不再适用。

解决方案：引入“指针”字段

为了克服安全规则无法迭代的限制，我们可以采用一种策略：在客户端进行写入操作时，除了添加动态字段本身，还同时写入一个已知字段，用于存储这个动态字段的名称（即UUID）。这个已知字段充当一个“指针”，指明了本次写入操作中哪个动态字段被添加或修改了。

客户端代码修改

首先，修改客户端代码，在更新文档时，将动态生成的UUID同时赋值给一个预设的“指针”字段（例如 newField）：

import { doc, updateDoc } from "firebase/firestore"; import { db } from "./firebaseConfig";  const docRef = doc(db, "yourCollection", "documentId");  const uuid = crypto.randomUUID(); // 生成UUID一次  await updateDoc(docRef, {     newField: uuid, // 将UUID写入一个已知字段作为指针     [uuid]: {       // 使用UUID作为动态字段名             name: 'Sally',             age: 24,     } });

通过这种方式，每次添加新的动态字段时，newField 字段都会被更新为最新添加的动态字段的UUID。

Check for AI

在论文、电子邮件等中检测AI书写的文本

85

查看详情

安全规则实现

有了 newField 这个指针，我们就可以在Firestore安全规则中获取到动态字段的名称，进而对其内容进行精确的结构校验。

以下是一个示例安全规则：

rules_version = '2'; service cloud.firestore {   match /databases/{database}/documents {     match /yourCollection/{documentId} {       allow read: if true; // 允许读取        allow update: if isValidDynamicField(request.resource.data);        function isValidDynamicField(newData) {         // 1. 确保新添加了newField字段，并且其值是字符串         //    同时确保newField指向的动态字段存在于新数据中         let newFieldKey = newData.newField;         return newFieldKey is string && newData[newFieldKey] is map &&                // 2. 校验动态字段的结构                newData[newFieldKey].name is string &&                newData[newFieldKey].age is number;       }     }   } }

规则解析：

1. allow update: if isValidDynamicField(request.resource.data);: 当文档被更新时，调用 isValidDynamicField 函数来校验请求的数据。
2. let newFieldKey = newData.newField;: 从请求的数据中获取 newField 字段的值，即动态字段的UUID。
3. newFieldKey is string && newData[newFieldKey] is map:
   • 首先，确保 newFieldKey 存在且是一个字符串。
   • 其次，使用方括号 newData[newFieldKey] 来动态访问由 newFieldKey 指向的字段，并确保它是一个映射（map）。
4. newData[newFieldKey].name is string && newData[newFieldKey].age is number: 最后，对动态字段内部的 name 和 age 字段进行具体的类型校验。

通过这种方式，即使字段名是动态的，安全规则也能准确地定位并校验其结构。

注意事项与最佳实践

• 原子性操作： 确保客户端在一次 updateDoc 操作中同时写入 newField 和动态字段。如果分两次写入，安全规则可能无法在第一次写入时正确校验，或在第二次写入时丢失 newField 的上下文。
• 字段冲突： 如果文档中存在其他字段也名为 newField，可能会导致混淆。选择一个清晰且不常用的字段名作为指针。
• 写入权限： 确保用户有权限写入 newField 字段。在上述规则中，newField 的写入被包含在 isValidDynamicField 函数的校验范围内。
• 多字段更新： 上述方法适用于每次只添加或修改一个动态字段的场景。如果需要在一个操作中添加或修改多个动态字段，并且每个字段都需要独立校验，那么 newField 可能需要被设计为一个数组或其他更复杂的结构，安全规则也会相应变得更复杂。
• 字段清理（可选）： newField 字段在完成校验后，其作用就已达成。您可以选择在后续操作中清除或更新它，或者让它始终指向最新添加的动态字段。在许多场景下，让它指向最新添加的字段即可，因为它只在 update 操作时被用来定位校验目标。

总结

在Firestore中校验动态命名字段的结构是一个常见的挑战，但通过引入一个“指针”字段，我们可以有效地克服安全规则无法直接迭代的限制。通过在客户端代码中同步写入动态字段名到已知字段，并利用安全规则动态读取该字段名来访问和校验目标字段，我们能够确保数据的一致性和完整性，即使面对高度动态的数据结构。这种策略提供了一个强大而灵活的解决方案，适用于需要对未知或动态键进行结构验证的场景。