กฎความปลอดภัยสำหรับการดำเนินการในไปป์ไลน์

แม้ว่าการดำเนินการในไปป์ไลน์จะมีฟีเจอร์มากมาย แต่เครื่องมือจัดการกฎจะจำกัดเฉพาะการจดจำตัวกรองการเปรียบเทียบ (เช่น >) และตัวกรองเชิงตรรกะ (เช่น or) เพื่อให้มั่นใจว่าข้อจำกัดจะสามารถตอบสนองได้และมีความปลอดภัย

นิพจน์ตัวกรองที่รองรับ

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

• การเปรียบเทียบ: eq, neq, gt, gte, lt, lte, in, arrayContains
• ตรรกะ: and, or

ตัวอย่างเช่น

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

พร็อพเพอร์ตี้คำขอ

คุณยังคงใช้ request ออบเจ็กต์เพื่อตรวจสอบสิทธิ์และบริบทการค้นหาได้ แต่ระบบจะไม่รองรับพร็อพเพอร์ตี้บางอย่าง ที่มีในการค้นหามาตรฐานในการดำเนินการไปป์ไลน์

ที่พักที่รองรับ

เครื่องมือใหม่ยังคงรองรับพร็อพเพอร์ตี้ต่อไปนี้

• request.auth: เข้าถึงข้อมูล uid และโทเค็นของผู้ใช้
• request.method: ระบุการดำเนินการ (เช่น get, list)
• request.path: เส้นทางของทรัพยากรที่เข้าถึง
• request.time: การประทับเวลาฝั่งเซิร์ฟเวอร์ของคำขอ

พร็อพเพอร์ตี้ที่ไม่รองรับ

ระบบไม่รองรับพร็อพเพอร์ตี้ request.query เช่น limit, offset และ orderBy สำหรับการตรวจสอบกฎการดำเนินการของไปป์ไลน์เนื่องจากความซับซ้อนในการกำหนดค่าเหล่านี้ในการค้นหาแบบหลายขั้นตอน

การจัดการสิทธิ์และขั้นตอนของไปป์ไลน์

ขั้นตอนต่างๆ ของไปป์ไลน์จะเชื่อมโยงกับการดำเนินการแบบละเอียดที่เฉพาะเจาะจงใน กฎความปลอดภัย ดังนี้

• สิทธิ์ allow list: ทริกเกอร์โดยขั้นตอน collection(), collectionGroup() และ database()
• allow get permissions: ทริกเกอร์โดยdocuments() stage ซึ่ง ได้รับการปฏิบัติคล้ายกับการดำเนินการแบบกลุ่ม get
• ขั้นตอนค่าคงที่: ขั้นตอน literals() จะไม่อ่านจากฐานข้อมูล แต่ อาจทำให้เกิดค่าใช้จ่ายได้ โดยต้องจับคู่กับอีกขั้นตอนหนึ่ง (เช่น collection()) ที่กฎสามารถยืนยันได้เพื่อป้องกันการละเมิด

ขั้นตอนการแก้ไขฟิลด์

กฎจะทำงานกับข้อมูลที่จัดเก็บเท่านั้น ไม่ใช่ค่าที่ได้มา หากไปป์ไลน์มีขั้นตอนที่แก้ไขฟิลด์ (เช่น add_fields(...), replace_with(...), select(...), remove_fields(...)) เครื่องมือจัดการกฎจะหยุดใช้ข้อจํากัดของตัวกรองหลังจากพบขั้นตอนนั้น หากต้องการให้กฎทํางานตามที่คาดไว้ ให้วางตําแหน่งขั้นตอนตัวกรอง (เช่น where) ก่อนขั้นตอนที่แก้ไขเอกสารต้นฉบับที่จัดเก็บไว้ได้

ตัวอย่างเช่น ลองดูที่กฎความปลอดภัยต่อไปนี้

match /databases/{database}/documents {
  match /cities/{city} {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    allow read: if resource.data.visibility == 'public';
  }
}

ถูกปฏิเสธ: กฎนี้ปฏิเสธไปป์ไลน์ต่อไปนี้เนื่องจากaddFieldsระยะ เกิดขึ้นก่อนการกรองเอกสารที่ visibility เป็น public

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

อนุญาต: กฎนี้อนุญาตให้ใช้ไปป์ไลน์ต่อไปนี้เนื่องจากขั้นตอน where(eq(field("visibility"), constant("public"))) เกิดขึ้นก่อนขั้นตอนการแก้ไขใดๆ

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();