Firestore安全规则中动态字段验证的挑战
在Firestore中，有时我们需要存储结构化数据，其中字段名称是动态生成的，例如使用UUID作为键来存储一系列子对象。考虑以下文档结构，其中-6e219b89-98fb-44cd-b6ad-e22888b6fb2f和-345c635a-11cb-4165-86ef-50be50794532是动态生成的UUID：
// Firestore Document
{
"-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（数字类型）的Map。然而，Firestore安全规则的一个核心限制是它们无法迭代或动态推断字段名称。规则必须明确知道要检查的字段路径。例如，如果字段名已知，我们可以这样写规则：
// 假设字段名已知为 'someKnownField'
allow write: if request.resource.data.someKnownField.name is string &&
request.resource.data.someKnownField.age is number;但对于动态生成的UUID字段，这种直接的路径引用是不可行的，因为在编写规则时我们无法预知其名称。
解决方案：引入已知引用字段
为了解决这个问题，我们可以采用一种策略：在客户端写入动态字段的同时，额外写入一个“已知”字段，用于存储这个动态字段的键（UUID）。这样，Firestore安全规则就可以通过这个已知的字段来获取动态字段的名称，并进而验证其结构。
客户端代码修改
修改后的客户端写入操作将包含两部分：一是实际的动态字段及其数据，二是用于存储动态字段键的引用字段（例如，命名为newField）。
import { doc, updateDoc } from 'firebase/firestore';
import { db } from './firebaseConfig'; // 假设你的Firestore实例
async function addNewPerson(docId) {
const docRef = doc(db, 'yourCollection', docId); // 替换为你的集合和文档ID
const uuid = crypto.randomUUID(); // 生成动态UUID
await updateDoc(docRef, {
newField: uuid, // 存储新添加字段的UUID
[uuid]: { // 动态字段
name: 'Sally',
age: 24,
}
});
console.log(`Successfully added new person with UUID: ${uuid}`);
}
// 示例调用
// addNewPerson('someDocumentId');在这个修改后的操作中，newField字段的值将是新添加的动态字段（例如uuid）的键。
安全规则的实现
现在，Firestore安全规则可以利用request.resource.data.newField来获取动态字段的名称，然后使用方括号语法来访问和验证该动态字段的结构。
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /yourCollection/{docId} { // 替换为你的集合路径
allow update: if request.resource.data.newField is string && // 确保newField存在且是字符串
request.resource.data[request.resource.data.newField] is map && // 确保动态字段是一个map
request.resource.data[request.resource.data.newField].name is string && // 验证name字段
request.resource.data[request.resource.data.newField].age is number; // 验证age字段
}
}
}规则解释：
- request.resource.data.newField is string: 这条规则首先检查更新操作中是否存在一个名为newField的字段，并确保其类型为字符串。这是获取动态键的前提。
- request.resource.data[request.resource.data.newField] is map: 接下来，我们使用方括号语法request.resource.data[dynamicKey]来访问由newField所指向的动态字段。这条规则验证该动态字段本身是否为一个Map类型。
- request.resource.data[request.resource.data.newField].name is string: 进一步验证动态Map内部的name字段是否存在且为字符串类型。
- request.resource.data[request.resource.data.newField].age is number: 验证动态Map内部的age字段是否存在且为数字类型。
通过这种方式，即使字段名是动态的，安全规则也能通过一个已知的中间字段来“定位”并验证其结构和内容。
注意事项与最佳实践
-
newField的生命周期管理：
- 一次性验证： 如果newField仅仅用于验证新添加的字段，并且在验证完成后不再需要，你可能需要在成功写入后，通过另一个客户端操作将其删除（但要注意这会产生额外的写入操作和潜在的竞态条件）。
- 持久化： 在许多场景下，newField可以被视为一个元数据字段，即使在验证后保留下来也无妨，甚至可以用于后续的查询或管理目的。
- 多字段添加： 如果一次性添加多个动态字段，你需要为每个字段设计一个引用机制，或者重新考虑数据模型，例如将所有动态字段放入一个子集合或一个已知名称的Map中。
- 数据模型设计： 这种方法适用于在单个文档中添加少量动态字段的场景。如果动态字段数量非常大或频繁变动，考虑使用子集合来存储这些动态数据，因为子集合的文档ID本身就是动态的，且更容易通过集合级别的规则进行管理。
- 规则的粒度与复杂性： 随着动态字段结构变得复杂，安全规则也会相应增长。确保规则的可读性和可维护性。对于更复杂的结构，可以考虑使用自定义函数来封装验证逻辑。
- 原子性： 客户端的updateDoc操作是原子的，即newField和动态UUID字段要么一起成功写入，要么一起失败。这确保了安全规则总能找到newField来引用动态字段。
总结
尽管Firestore安全规则不直接支持迭代动态字段，但通过引入一个“已知引用字段”来存储动态字段的键，我们可以有效地绕过这一限制。这种方法使得安全规则能够精确地定位并验证新添加的动态字段的结构和数据类型，从而在保持数据模型灵活性的同时，确保了数据完整性和安全性。在实施时，需根据实际需求权衡newField的生命周期管理和整体数据模型设计。
