我在 Firestore 中有“组”。每个组都有一个“成员”键。我的目标是编写 Firebase 存储安全规则，以仅允许“写入”组成员：
# I want something like this
match /groups/{groupId} {
allow read, write: if request.auth.uid in get(/database/groups/{groupId}/members);
}
【问题讨论】：
标签： firebase google-cloud-firestore google-cloud-storage firebase-security
安全规则无法从其他服务读取，因此您将无法按照您在此处描述的方式实施组。相反，您必须在您的规则本身或用户的 ID 令牌中（作为自定义声明）对某人属于哪些组的知识进行编码。
对于后者的示例，请参阅 making data "group private" 上的 Firebase 文档中的这个 sn-p：
另一个同样常见的用例是允许对对象的组权限，例如允许多个团队成员在共享文档上进行协作。有几种方法可以做到这一点：
创建一个 Firebase 身份验证自定义令牌，其中包含有关群组成员的其他信息（例如群组 ID）
在文件元数据中包含组信息（例如组 ID 或授权 uid 列表）
一旦此数据存储在令牌或文件元数据中，就可以从规则中引用它：
// Allow reads if the group ID in your token matches the file metadata's `owner` property // Allow writes if the group ID is in the user's custom token match /files/{groupId}/{fileName} { allow read: if resource.metadata.owner == request.auth.token.groupId; allow write: if request.auth.token.groupId == groupId; }
如今，您无需创建完整的自定义令牌来包含组 ID，但您可以通过 Firebase Admin SDK 来include information in a regular token as a custom claim。例如在 Node.js 中，您可以添加一个 groupId 就像上面使用的那样：
admin.auth().setCustomUserClaims(uid, {groupId: "group"})
这种方法适用于您可以清楚地识别用户所属的单个组（或一小组组）的情况。如果您获得包含包含和排除的大型组成员层次结构，则在声明中捕获它们会变得更加困难，尤其是所有声明必须小于 1,000 字节。
另一种方法是将关于组成员的知识嵌入到规则本身中。在这种情况下，您将采用您现在在数据库中拥有的结构，并将其编码到您的规则中。
如果您的群组成员相当稳定，您可以手动执行此操作。在这种情况下，您最终会在安全规则中使用硬编码的 UID。
但是由于您选择将组成员身份存储在数据库中，这些成员身份可能至少在某种程度上是动态的。在这种情况下，您可能希望结合使用以前的方法来捕获部分成员资格，然后为其他部分生成安全规则。
然后，您可以定期部署生成的规则，也可以在组成员更改时部署。
虽然这是一种比（仅）将信息嵌入用户令牌中更暴力的方法，但我已经看到它被用于创建高级成员资格测试。我主要不喜欢它，是生成的安全规则往往变得不可读。您可以通过在规则中将“组检查”生成到单独的函数中来缓解这种情况，以便手写规则（您将更频繁地阅读）可以只包括对 isMemberOfValidGroup(...) 的调用或类似的东西。
【讨论】：