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

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

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

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 เสมอ แม้ว่ากฎที่ 1 จะเป็น false เสมอก็ตาม

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

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

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

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