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

แม้ว่าการดำเนินการไปป์ไลน์จะมีฟีเจอร์มากมาย แต่กลไกกฎจะจำกัดให้รู้จักเฉพาะตัวกรองการเปรียบเทียบ (เช่น >) และตัวกรองเชิงตรรกะ (เช่น 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 สิทธิ์: ทริกเกอร์โดยขั้นตอน documents() ซึ่งจะได้รับการปฏิบัติคล้ายกับการดำเนินการ 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();