การจัดโครงสร้างกฎความปลอดภัยของ Cloud Firestore

กฎความปลอดภัยของ Cloud Firestore ช่วยให้คุณควบคุมการเข้าถึงเอกสารและ ในฐานข้อมูลของคุณ ไวยากรณ์กฎที่ยืดหยุ่นช่วยให้คุณสามารถสร้าง กฎที่ตรงกับอะไรก็ได้ ตั้งแต่การเขียนทั้งหมดไปจนถึงฐานข้อมูลทั้งหมดไปจนถึงการดำเนินการ ในเอกสารที่ระบุ

คู่มือนี้จะอธิบายไวยากรณ์และโครงสร้างพื้นฐานของกฎความปลอดภัย รวม ไวยากรณ์ที่มีเงื่อนไขกฎความปลอดภัยในการสร้าง ชุดกฎที่สมบูรณ์

การประกาศบริการและฐานข้อมูล

กฎความปลอดภัยของ Cloud Firestore จะเริ่มต้นด้วยการประกาศต่อไปนี้เสมอ

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

การประกาศ service cloud.firestore จะกำหนดกฎไว้ที่ Cloud Firestore ป้องกันความขัดแย้งระหว่างกฎการรักษาความปลอดภัยของ Cloud Firestore และ สำหรับผลิตภัณฑ์อื่นๆ เช่น 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

อย่างไรก็ตาม โปรดทราบว่าลักษณะการทำงานของไวลด์การ์ดที่เกิดซ้ำจะขึ้นอยู่กับกฎ เวอร์ชัน

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>;
    }
  }
}

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 เสมอ แม้ว่ากฎแรก กฎคือ false เสมอ

ขีดจำกัดของกฎความปลอดภัย

โปรดคำนึงถึงขีดจำกัดต่อไปนี้เมื่อทำงานกับกฎความปลอดภัย

ขั้นตอนถัดไป

• เขียนเงื่อนไขของกฎความปลอดภัยที่กำหนดเอง
• โปรดอ่านข้อมูลอ้างอิงกฎความปลอดภัย