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

แม้ว่าการดำเนินการในไปป์ไลน์จะมีฟีเจอร์มากมาย แต่เครื่องมือจัดการกฎจะถูกจำกัดการรับรู้ตัวกรองการเปรียบเทียบ (เช่น >) และตัวกรองเชิงตรรกะ (เช่น 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: Triggered by the documents() stage, which is treated similarly to a batch get operation.
  • ขั้นตอนตัวอักษร: ขั้นตอน 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();