我试图学习使用Google Cloud Firestore存储和保护一些简单数据,因此我开始编写一些基本规则来验证从API传递的数据是否合理。
我最初的想法是,每个规则都会被评估,如果任何一个规则失败,它将无法通过请求,但我发现请求并且不符合规则仍然是成功的。有人可以解释如何为子集合创建逐步加强的安全规则吗?
这是我目前的规则集:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read;
allow write: if request.auth.uid != null;
}
match /projects {
allow write: if resource.data.keys().hasAll(['title', 'description']);
}
}
}
答案 0 :(得分:1)
我执行以下规则:
一旦规则返回true,就不会因为其他匹配而使它失败或再次使其为false。
注意:为了节省不必要的费用,在大多数情况下,按最有可能返回true的顺序放置比赛。
还尝试创建可重用的功能。
这是我发现的最好的资源之一。 https://www.fullstackfirebase.com/cloud-firestore/security-rules
答案 1 :(得分:0)
在Firestore规则中,如果有任何allow
批准了该请求,则该请求被允许。应用于任何给定请求的allow
语句都是与资源名称匹配的所有match
块。
由于match /{document=**}
模式与match /projects
模式重叠,因此仅通过例如通过身份验证即可写入projects
文档。 request.auth.uid != null
。这可能不是预期的。
match /projects
与/databases/*/documents/projects
的长度是固定的匹配,而match /{document=**}
将匹配以/databases/*/documents
开头的任何文档名称。 **
的存在指示零个或更多其他路径。
通常,最好避免在match
模式中出现重叠。如果您需要编写一条与大多数事物匹配但又为特定路径排除异常的规则,则该规则应如下所示:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read;
// allow writes to anything except the 'projects' document.
allow write: if request.auth.uid != null
&& /databases/$(database)/documents/$(document)
!= /databases/$(database)/documents/projects
}
match /projects {
// allow _authenticated_ writes to the projects document if they
// have the proper form.
allow write: if request.auth.uid != null
&& resource.data.keys().hasAll(['title', 'description']);
}
}
}