本教程探讨了在Firestore安全规则中验证动态命名字段结构（如UUID作为键的Map）的挑战。由于安全规则无法直接迭代或预知动态字段名，文章提出了一种实用策略：在客户端写入操作中引入一个辅助字段来存储动态键。通过此辅助字段，安全规则能够准确引用并验证新添加动态字段的内部结构，确保数据完整性和安全性。

理解Firestore安全规则的局限性

在firestore中，我们经常会遇到需要存储动态键值对的场景，例如使用uuid作为map的键来存储一系列结构化数据。考虑以下文档结构，其中 -6e219b89-98fb-44cd-b6ad-e22888b6fb2f 和 -345c635a-11cb-4165-86ef-50be50794532 都是随机生成的uuid：

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

当客户端代码尝试添加一个新的动态字段时，例如：

await updateDoc(docRef, {     [crypto.randomUUID()]: {             name: 'Sally',             age: 24,     } });

我们希望通过Firestore安全规则来验证新添加的字段是否符合预期的结构，即 name 字段必须是字符串，age 字段必须是数字。然而，Firestore安全规则的一个核心限制是它们无法迭代文档中的字段，也无法预知动态生成的字段名。这意味着，我们不能直接编写类似 request.resource.data.*.name is string 这样的规则来匹配所有动态字段。规则必须始终知道要检查的确切字段路径。

如果已知字段名，我们可以轻松编写规则：

// 假设我们知道字段名是 'knownField' allow update: if request.resource.data.knownField.name is string &&                  request.resource.data.knownField.age is number;

但在动态字段场景下，由于UUID是随机生成的，这种直接的验证方式便失效了。

解决方案：引入辅助字段进行动态键追踪

为了克服Firestore安全规则无法预知动态字段名的限制，我们可以采用一种策略：在客户端写入操作中，除了添加动态字段本身，还引入一个“辅助字段”（或称“追踪字段”）来存储这个动态字段的键（即UUID）。这样，安全规则就可以通过读取这个已知的辅助字段来获取动态键，进而定位并验证对应的动态字段。

客户端代码修改

首先，我们需要修改客户端的写入逻辑，使其在更新文档时，同时写入动态字段及其对应的UUID到一个预设的辅助字段中。例如，我们可以将辅助字段命名为 newField：

集简云

软件集成平台，快速建立企业自动化与智能化

21

查看详情

import { doc, updateDoc } from "firebase/firestore"; import { db } from "./firebaseConfig"; // 假设这是你的Firestore实例  const docRef = doc(db, "yourCollection", "yourDocumentId");  // 生成动态键 const uuid = crypto.randomUUID();  // 执行更新操作，同时写入动态字段和辅助字段 await updateDoc(docRef, {     newField: uuid, // 辅助字段，存储新添加的动态键     [uuid]: {       // 动态字段             name: 'Sally',             age: 24,     } });

在这个修改后的操作中，newField 将保存 uuid 的值，而 [uuid] 则是实际包含 name 和 age 的Map。

Firestore安全规则配置

有了客户端的配合，我们现在可以在Firestore安全规则中利用 newField 来验证动态字段的结构。规则将首先读取 newField 的值，然后使用这个值作为键来访问 request.resource.data 中对应的动态字段。

rules_version = '2'; service cloud.firestore {   match /databases/{database}/documents {     match /yourCollection/{documentId} {       allow read: if true; // 允许读取        allow update: if isValidNewDynamicField(request.resource.data);        function isValidNewDynamicField(data) {         // 1. 确保 newField 存在且是字符串         // 2. 获取新添加字段的键         let newKey = data.newField;         return newKey is string &&                 // 3. 验证新添加的动态字段是否存在                data[newKey] is map &&                 // 4. 验证动态字段内部的 'name' 字段                data[newKey].name is string &&                 // 5. 验证动态字段内部的 'age' 字段                data[newKey].age is number;       }     }   } }

规则解析：

1. isValidNewDynamicField(data) 函数： 定义一个辅助函数来封装验证逻辑，提高可读性。
2. newKey is string： 首先验证 newField 字段是否存在并且其值是一个字符串，这确保了我们能安全地获取动态键。
3. data[newKey] is map： 检查通过 newKey 访问到的字段是否存在并且是一个Map类型，这是我们期望的结构。
4. data[newKey].name is string： 验证动态字段中的 name 属性是否存在且为字符串类型。
5. data[newKey].age is number： 验证动态字段中的 age 属性是否存在且为数字类型。

通过这种方式，即使动态字段的名称是未知的UUID，我们仍然能够利用 newField 这个“桥梁”在安全规则中对其进行精确的结构验证。

注意事项与最佳实践

1. 原子性： 确保客户端在一次 updateDoc 操作中原子性地写入 newField 和动态字段。如果分两次写入，可能导致在 newField 写入后、动态字段写入前，规则验证失败或产生不一致状态。
2. newField 的生命周期：
   • 如果 newField 仅用于验证当前写入的单个动态字段，并且每次更新只添加一个动态字段，那么在规则验证完成后，newField 可以被清除（通过后续的 updateDoc({ newField: FieldValue.delete() })）。
   • 如果您的应用场景允许一次更新添加多个动态字段，或者 newField 有其他用途，则可能需要调整策略，例如使用一个数组来存储所有新添加的动态键，或者考虑将动态数据存储在子集合中，因为子集合的文档ID本身就是动态键，更符合Firestore的推荐实践。
3. 安全性： 确保 newField 本身不能被恶意用户篡改以绕过规则。在上述规则中，我们已经验证了 newField 的类型，并且其值是用来索引 request.resource.data 中的新字段。
4. 可读性与维护性： 使用函数 (isValidNewDynamicField) 可以使安全规则更模块化、更易读、更易于维护。

总结

Firestore安全规则在处理动态字段时面临挑战，因为它们无法直接迭代或预知字段名。通过在客户端写入操作中引入一个辅助字段来存储动态键，我们为安全规则提供了一个明确的引用路径。这种策略使得安全规则能够准确地定位并验证新添加的动态字段的内部结构，从而有效地增强了数据完整性和应用程序的安全性。在设计此类数据模型时，结合客户端写入逻辑和服务器端安全规则的协同工作是实现健壮数据验证的关键。