Cloud Firestore Security Rules ช่วยให้คุณสามารถควบคุมการเข้าถึงเอกสารและ คอลเล็กชันในฐานข้อมูลของคุณ รูปแบบคำสั่งของกฎที่ยืดหยุ่นช่วยให้คุณสร้างกฎที่ตรงกับทุกสิ่งได้ ตั้งแต่การเขียนทั้งหมดไปยังทั้งฐานข้อมูลไปจนถึงการดำเนินการในเอกสารที่เฉพาะเจาะจง
คู่มือนี้จะอธิบายไวยากรณ์และโครงสร้างพื้นฐานของกฎความปลอดภัย รวมรูปแบบคำสั่งนี้เข้ากับเงื่อนไขของกฎความปลอดภัยเพื่อสร้างชุดกฎที่สมบูรณ์
การประกาศบริการและฐานข้อมูล
Cloud Firestore Security Rules ขึ้นต้นด้วยการประกาศต่อไปนี้เสมอ
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
การประกาศ service cloud.firestore
จะกำหนดขอบเขตของกฎเป็น Cloud Firestore ซึ่งจะช่วยป้องกันไม่ให้ Cloud Firestore Security Rules ขัดแย้งกับกฎสำหรับผลิตภัณฑ์อื่นๆ เช่น Cloud Storage
การประกาศ match /databases/{database}/documents
จะระบุว่ากฎควรตรงกับฐานข้อมูล Cloud Firestore ในโปรเจ็กต์ ปัจจุบันแต่ละโปรเจ็กต์
มีฐานข้อมูลเดียวที่ชื่อ (default)
กฎการอ่าน/เขียนพื้นฐาน
กฎพื้นฐานประกอบด้วยคำสั่ง match
ที่ระบุเส้นทางของเอกสารและ
อนุญาตนิพจน์ allow
ที่ระบุรายละเอียดเมื่ออ่านข้อมูลที่ระบุ:
service cloud.firestore {
match /databases/{database}/documents {
// Match any document in the 'cities' collection
match /cities/{city} {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
ข้อความที่ตรงกันทั้งหมดควรชี้ไปยังเอกสาร ไม่ใช่คอลเล็กชัน คำสั่งการจับคู่สามารถชี้ไปยังเอกสารที่เฉพาะเจาะจง เช่น match /cities/SF
หรือใช้ไวลด์การ์ดเพื่อชี้ไปยังเอกสารใดก็ได้ในเส้นทางที่ระบุ เช่น match /cities/{city}
ในตัวอย่างด้านบน คำสั่งจับคู่จะใช้ไวยากรณ์ไวลด์การ์ด {city}
กฎนี้จะมีผลกับเอกสารในคอลเล็กชัน cities
เช่น
/cities/SF
หรือ/cities/NYC
เมื่อนิพจน์ allow
ในคำสั่งจับคู่
ประเมินแล้ว ตัวแปร city
จะเปลี่ยนเป็นชื่อเอกสารของเมือง
เช่น SF
หรือ NYC
การดำเนินการแบบละเอียด
ในบางสถานการณ์ การจำแนก read
และ write
เป็นรายละเอียดเพิ่มเติมอาจมีประโยชน์
การดำเนินงานแบบละเอียด เช่น แอปของคุณอาจต้องการบังคับใช้
เงื่อนไขในการสร้างเอกสารมากกว่าการลบเอกสาร หรือคุณอาจต้องการ
อนุญาตการอ่านเอกสารรายการเดียว แต่ปฏิเสธคำค้นหาจำนวนมาก
กฎ read
สามารถแบ่งออกเป็น get
และ list
ส่วนกฎ write
สามารถแบ่งออกเป็น create
, update
และ delete
ดังนี้
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// A write rule can be divided into create, update, and delete rules
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
ข้อมูลตามลําดับชั้น
ข้อมูลใน Cloud Firestore จะแบ่งออกเป็นคอลเล็กชันของเอกสาร และ อาจขยายลำดับชั้นผ่านคอลเล็กชันย่อย คุณจำเป็นต้องเข้าใจวิธีที่กฎการรักษาความปลอดภัยโต้ตอบกับข้อมูลลําดับชั้น
ลองพิจารณาสถานการณ์ที่เอกสารแต่ละรายการในคอลเล็กชัน cities
มีองค์ประกอบ
คอลเล็กชันย่อย landmarks
รายการ กฎความปลอดภัยจะมีผลเฉพาะกับเส้นทางที่ตรงกัน ดังนั้น
การควบคุมการเข้าถึงที่กำหนดไว้ในคอลเล็กชัน cities
จะไม่มีผลกับ
คอลเล็กชันย่อย landmarks
รายการ แต่ให้เขียนกฎที่ชัดเจนเพื่อควบคุมการเข้าถึงคอลเล็กชันย่อยแทน ดังนี้
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
allow read, write: if <condition>;
// Explicitly define rules for the 'landmarks' subcollection
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
เมื่อฝังคำสั่ง match
เส้นทางของคำสั่ง match
ภายในจะสัมพันธ์กับเส้นทางของคำสั่ง match
ภายนอกเสมอ ดังนั้นชุดกฎต่อไปนี้จึงมีความหมายเหมือนกัน
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city}/landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
ไวลด์การ์ดแบบย้อนกลับ
หากคุณต้องการใช้กฎกับลำดับชั้นขั้นสูงแบบไม่มีกฎเกณฑ์ ให้ใช้เมธอด
ไวยากรณ์ไวลด์การ์ดแบบวนซ้ำ {name=**}
เช่น
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{document=**} {
allow read, write: if <condition>;
}
}
}
เมื่อใช้ไวยากรณ์ไวลด์การ์ดที่เกิดซ้ำ ตัวแปรไวลด์การ์ดจะมีค่า
กลุ่มเส้นทางที่ตรงกันทั้งหมด แม้ว่าเอกสารจะอยู่ในตำแหน่งที่ซ้อนอยู่ลึก
คอลเล็กชันย่อย เช่น กฎที่แสดงด้านบนจะตรงกับ
เอกสารซึ่งอยู่ที่ /cities/SF/landmarks/coit_tower
และค่าของ
ตัวแปร document
จะเป็น SF/landmarks/coit_tower
อย่างไรก็ตาม โปรดทราบว่าลักษณะการทำงานของไวลด์การ์ดที่เกิดซ้ำจะขึ้นอยู่กับกฎ เวอร์ชัน
เวอร์ชัน 1
กฎความปลอดภัยจะใช้เวอร์ชัน 1 โดยค่าเริ่มต้น ในเวอร์ชัน 1 อักขระไวลด์การ์ดแบบย้อนกลับจะจับคู่กับรายการเส้นทางอย่างน้อย 1 รายการ รายการเหล่านี้จะไม่ตรงกับเส้นทางว่าง ดังนั้น match /cities/{city}/{document=**}
จะตรงกับเอกสารในคอลเล็กชันย่อยแต่ไม่ตรงกับในคอลเล็กชัน cities
ส่วน match /cities/{document=**}
จะตรงกับทั้งเอกสารในคอลเล็กชัน cities
และคอลเล็กชันย่อย
ไวลด์การ์ดแบบย้อนกลับต้องอยู่ท้ายคำสั่งการจับคู่
เวอร์ชัน 2
ในกฎความปลอดภัยเวอร์ชัน 2 ไวลด์การ์ดที่เกิดซ้ำจะจับคู่กับเส้นทาง 0 รายการขึ้นไป
รายการ match/cities/{city}/{document=**}
ตรงกับเอกสารใน
คอลเล็กชันย่อย และเอกสารในคอลเล็กชัน cities
คุณต้องเลือกใช้เวอร์ชัน 2 โดยเพิ่ม rules_version = '2';
ที่ด้านบนสุดของ
กฎความปลอดภัยของคุณ:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{city}/{document=**} {
allow read, write: if <condition>;
}
}
}
คุณมีไวลด์การ์ดแบบย้อนกลับได้สูงสุด 1 รายการต่อคำสั่งการจับคู่ แต่ในเวอร์ชัน 2 คุณสามารถวางไวลด์การ์ดนี้ไว้ที่ใดก็ได้ในคำสั่งการจับคู่ เช่น
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the songs collection group
match /{path=**}/songs/{song} {
allow read, write: if <condition>;
}
}
}
หากใช้การค้นหากลุ่มคอลเล็กชัน คุณต้องใช้เวอร์ชัน 2 โปรดดูการรักษาความปลอดภัยให้กับการค้นหากลุ่มคอลเล็กชัน
คำสั่งการจับคู่ที่ทับซ้อนกัน
เอกสารอาจตรงกับmatch
คำสั่งได้มากกว่า 1 รายการ ในกรณีที่นิพจน์ allow
หลายรายการตรงกับคําขอ ระบบจะอนุญาตการเข้าถึงหากเงื่อนไขใดหนึ่งเป็น true
ดังนี้
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the 'cities' collection.
match /cities/{city} {
allow read, write: if false;
}
// Matches any document in the 'cities' collection or subcollections.
match /cities/{document=**} {
allow read, write: if true;
}
}
}
ในตัวอย่างข้างต้น ระบบจะอนุญาตการอ่านและการเขียนทั้งหมดในคอลเล็กชัน cities
เนื่องจากกฎที่ 2 เป็น true
เสมอ แม้ว่ากฎที่ 1 จะเป็น false
เสมอก็ตาม
ขีดจำกัดของกฎความปลอดภัย
โปรดคำนึงถึงขีดจำกัดต่อไปนี้เมื่อทำงานกับกฎความปลอดภัย
ขีดจำกัด | รายละเอียด |
---|---|
จำนวนการโทรสูงสุด exists() , get() และ getAfter() ต่อคำขอ |
หากเกินขีดจำกัดดังกล่าว ระบบจะแสดงข้อผิดพลาด "ถูกปฏิเสธสิทธิ์" การเรียกการเข้าถึงเอกสารบางรายการอาจถูกแคชไว้ และการโทรที่แคชไว้จะไม่นับรวมในขีดจำกัด |
ความลึกสูงสุดของคำสั่ง match ที่ฝังอยู่ |
10 |
ความยาวเส้นทางสูงสุดในกลุ่มเส้นทาง อนุญาตภายในชุดที่ซ้อนกัน
รายการบัญชี match รายการ |
100 |
จำนวนตัวแปรการเก็บเส้นทางสูงสุดที่อนุญาตภายในชุดของ
คำสั่ง match ที่ฝัง |
20 |
ความลึกของการเรียกใช้ฟังก์ชันสูงสุด | 20 |
จำนวนอาร์กิวเมนต์ของฟังก์ชันสูงสุด | 7 |
จำนวนการเชื่อมโยงตัวแปรสูงสุด let รายการต่อฟังก์ชัน |
10 |
จำนวนสูงสุดของการเรียกใช้ฟังก์ชันแบบเวียนเกิดหรือแบบวนซ้ำ | 0 (ไม่ได้รับอนุญาต&r; |
จำนวนนิพจน์สูงสุดที่ประเมินต่อคำขอ | 1,000 ราย |
ขนาดสูงสุดของชุดกฎ | ชุดกฎจะต้องเป็นไปตามขีดจำกัด 2 ขนาดดังนี้
|