本文探讨了如何在Firestore中使用安全规则验证带有动态（随机UUID）键的新增字段的结构。由于Firestore安全规则无法直接迭代或预知动态字段名，文章提出了一种通过引入一个已知辅助字段来存储动态键的解决方案，从而使安全规则能够获取该键并对相应的新增数据结构进行精确验证。

挑战：动态字段的结构化验证

在firestore中，有时我们需要向文档添加具有动态键（例如，使用crypto.randomuuid()生成的唯一标识符）的字段，这些字段的值通常是结构化的数据（如map）。例如，一个文档可能包含一系列以uuid作为键的用户信息：

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

当客户端代码尝试添加一个新的用户记录时，它会生成一个随机UUID作为新字段的键：

// 客户端添加新字段的操作 await updateDoc(docRef, {     [crypto.randomUUID()]: {             name: 'Sally',             age: 24,     } });

此时，核心问题在于：如何在Firestore安全规则中验证这个新添加的、键名未知的字段，确保其内部结构（例如，name是字符串，age是数字）符合预期？直接使用request.resource.data.name is string这样的规则是无效的，因为它无法预知动态的UUID键。Firestore安全规则的一个主要限制是它们不能迭代文档中的字段，也不能在规则定义时动态地获取并使用一个未知字段的键。

解决方案：引入辅助字段

为了克服安全规则的这一限制，我们可以采用一种策略：在执行写入操作时，除了添加动态字段本身，还额外引入一个“辅助字段”（helper field），用于存储这个动态字段的键。这样，安全规则就可以通过读取这个已知的辅助字段来获取动态键，进而验证对应的动态字段。

客户端代码修改：

首先，修改客户端的写入逻辑，使其在更新文档时，同时写入动态字段及其键到一个预设的辅助字段中。

// 修改后的客户端代码 const uuid = crypto.randomUUID(); // 生成动态键 await updateDoc(docRef, {     newField: uuid, // 辅助字段：存储新添加字段的UUID     [uuid]: {       // 动态字段：实际的数据             name: 'Sally',             age: 24,     } });

在这个修改后的操作中，newField是一个固定的、已知的字段名，它的值就是新添加的动态字段的UUID。

集简云

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

21

查看详情

编写Firestore安全规则进行验证

有了辅助字段newField，我们现在就可以在Firestore安全规则中实现对动态字段的结构化验证了。规则的逻辑将是：

1. 检查写入请求中是否存在newField。
2. 如果存在，获取newField的值，这个值就是新添加的动态字段的键。
3. 使用这个键来访问request.resource.data中对应的动态字段，并对其内部结构进行验证。

安全规则示例：

rules_version = '2'; service cloud.firestore {   match /databases/{database}/documents {     match /your_collection/{documentId} {       allow update: if request.resource.data.keys().hasAny(['newField']) && // 1. 检查是否存在辅助字段                        validateNewDynamicField(request.resource.data, resource.data); // 2. 调用函数进行验证     }      // 辅助函数：验证新添加的动态字段结构     function validateNewDynamicField(newData, currentData) {       let newFieldKey = newData.newField; // 获取动态字段的键       return newFieldKey is string &&      // 确保键是字符串              newData[newFieldKey] is map && // 确保动态字段是一个Map              newData[newFieldKey].name is string && // 验证name字段是字符串              newData[newFieldKey].age is number;    // 验证age字段是数字     }   } }

规则解析：

• request.resource.data.keys().hasAny([‘newField’]): 这部分规则首先检查传入的更新数据中是否包含newField这个辅助字段。这确保了只有通过这种方式添加动态字段的请求才会被进一步验证。
• validateNewDynamicField(request.resource.data, resource.data): 调用一个自定义函数来执行具体的验证逻辑。
  • newFieldKey = newData.newField: 在函数内部，我们通过newData.newField安全地获取到动态字段的实际键名。
  • newFieldKey is string: 验证获取到的键名确实是一个字符串。
  • newData[newFieldKey] is map: 验证使用这个键名访问到的数据是一个Map类型。
  • newData[newFieldKey].name is string 和 newData[newFieldKey].age is number: 最后，对动态字段Map内部的name和age字段进行类型验证。

注意事项与最佳实践

1. 原子性操作： 客户端在执行updateDoc时，务必确保newField和实际的动态字段是同一个原子性操作的一部分。如果newField没有被写入，或者写入了错误的键，安全规则将无法正确验证。
2. 辅助字段的生命周期： newField辅助字段的目的是为了验证新字段的创建。一旦新字段被成功验证并写入，newField本身可能就不再需要了。您可以选择在后续的更新操作中清除它，或者如果它对其他业务逻辑有帮助，也可以保留。如果选择清除，需要额外的客户端逻辑或Cloud Function来处理。
3. 读操作的安全性： 本教程主要关注写入时的结构验证。对于读取操作，如果需要基于动态键进行权限控制，则需要根据实际业务场景设计相应的规则。
4. 复杂性与替代方案： 对于极其复杂的验证逻辑，或者需要与外部服务交互的场景，Cloud Functions for Firebase可能是更强大的选择。然而，对于纯粹的结构和类型验证，安全规则通常是更高效且成本更低的方案。

总结

通过引入一个简单的辅助字段来存储动态生成的键，我们可以有效地绕过Firestore安全规则在处理未知字段名时的限制。这种方法使得我们能够在不牺牲安全性的前提下，对文档中动态添加的、结构化数据进行精确的类型和结构验证，从而确保数据的一致性和完整性。在设计Firestore数据模型和安全规则时，理解并利用这类模式对于构建健壮的应用至关重要。