Google 致力于为黑人社区推动种族平等。查看具体举措
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

ภาษากฎความปลอดภัย

กฎความปลอดภัยของ Firebase ใช้ประโยชน์จากภาษาแบบกำหนดเองที่ยืดหยุ่นและมีประสิทธิภาพซึ่งรองรับความซับซ้อนและรายละเอียดที่หลากหลาย คุณสามารถกำหนดให้กฎของคุณเฉพาะเจาะจงหรือโดยทั่วไปตามที่เหมาะสมสำหรับแอปของคุณ กฎฐานข้อมูลแบบเรียลไทม์ใช้ไวยากรณ์ที่ดูเหมือน JavaScript ในโครงสร้าง JSON กฎ Cloud Firestore และ Cloud Storage ใช้ภาษาตาม Common Expression Language (CEL) ซึ่งสร้างบน CEL ที่มีการ match และ allow คำสั่งที่รองรับการเข้าถึงที่ได้รับตามเงื่อนไข

อย่างไรก็ตามเนื่องจากเป็นภาษาที่กำหนดเองจึงมีช่วงการเรียนรู้ ใช้คู่มือนี้เพื่อทำความเข้าใจภาษาของกฎให้ดีขึ้นเมื่อคุณเจาะลึกลงไปในกฎที่ซับซ้อนมากขึ้น

เลือกผลิตภัณฑ์เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับกฎของผลิตภัณฑ์

โครงสร้างพื้นฐาน

Cloud Firestore

กฎความปลอดภัยของ Firebase ใน Cloud Firestore และ Cloud Storage ใช้โครงสร้างและไวยากรณ์ต่อไปนี้:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

แนวคิดหลักต่อไปนี้เป็นสิ่งสำคัญที่ต้องทำความเข้าใจเมื่อคุณสร้างกฎ:

  • คำขอ: วิธีการหรือวิธีการที่เรียกใช้ในคำสั่ง allow นี่คือวิธีการที่คุณอนุญาตให้เรียกใช้ วิธีมาตรฐานคือ get list create update และ delete read และ write วิธีการเปิดใช้งานในวงกว้างสะดวกสบายอ่านและเขียนการเข้าถึงฐานข้อมูลหรือจัดเก็บข้อมูลเส้นทางที่ระบุ
  • เส้นทาง: ฐานข้อมูลหรือที่เก็บข้อมูลซึ่งแสดงเป็นเส้นทาง URI
  • กฎ: คำสั่ง allow ซึ่งรวมถึงเงื่อนไขที่อนุญาตคำขอหากประเมินว่าเป็นจริง

แต่ละแนวคิดเหล่านี้มีการอธิบายรายละเอียดเพิ่มเติมด้านล่าง

การจัดเก็บเมฆ

กฎความปลอดภัยของ Firebase ใน Cloud Firestore และ Cloud Storage ใช้โครงสร้างและไวยากรณ์ต่อไปนี้:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

แนวคิดหลักต่อไปนี้เป็นสิ่งสำคัญที่ต้องทำความเข้าใจเมื่อคุณสร้างกฎ:

  • คำขอ: วิธีการหรือวิธีการที่เรียกใช้ในคำสั่ง allow นี่คือวิธีการที่คุณอนุญาตให้เรียกใช้ วิธีมาตรฐานคือ get list create update และ delete read และ write วิธีการเปิดใช้งานในวงกว้างสะดวกสบายอ่านและเขียนการเข้าถึงฐานข้อมูลหรือจัดเก็บข้อมูลเส้นทางที่ระบุ
  • เส้นทาง: ฐานข้อมูลหรือที่เก็บข้อมูลซึ่งแสดงเป็นเส้นทาง URI
  • กฎ: คำสั่ง allow ซึ่งรวมถึงเงื่อนไขที่อนุญาตคำขอหากประเมินว่าเป็นจริง

แต่ละแนวคิดเหล่านี้มีการอธิบายรายละเอียดเพิ่มเติมด้านล่าง

ฐานข้อมูลเรียลไทม์

ในฐานข้อมูลแบบเรียลไทม์กฎความปลอดภัยของ Firebase ประกอบด้วยนิพจน์คล้าย JavaScript ที่อยู่ในเอกสาร JSON

พวกเขาใช้ไวยากรณ์ต่อไปนี้:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

มีองค์ประกอบพื้นฐานสามประการในกฎ:

  • เส้นทาง: ตำแหน่งฐานข้อมูล สิ่งนี้สะท้อนโครงสร้าง JSON ของฐานข้อมูลของคุณ
  • คำขอ: เป็นวิธีการที่กฎใช้เพื่อให้สิทธิ์การเข้าถึง กฎการ read และ write ให้สิทธิ์ในการอ่านและเขียนในวงกว้างในขณะที่กฎการ validate ทำหน้าที่เป็นการตรวจสอบรองเพื่อให้สิทธิ์การเข้าถึงตามข้อมูลขาเข้าหรือข้อมูลที่มีอยู่
  • เงื่อนไข: เงื่อนไขที่อนุญาตให้มีการร้องขอหากประเมินว่าเป็นจริง

สร้างกฎ

Cloud Firestore

องค์ประกอบพื้นฐานของกฎใน Cloud Firestore และ Cloud Storage มีดังนี้:

  • การประกาศ service : ประกาศผลิตภัณฑ์ Firebase ที่กฎบังคับใช้
  • บล็อกการ match : กำหนดเส้นทางในฐานข้อมูลหรือที่เก็บข้อมูลที่ใช้กับกฎ
  • คำสั่ง allow : ให้เงื่อนไขในการให้สิทธิ์เข้าถึงโดยแยกตามวิธีการ วิธีการที่รองรับ ได้แก่ get , list , create , update , delete และวิธีการอำนวยความสะดวกในการ read และ write
  • function ประกาศ function เสริม: ให้ความสามารถในการรวมและรวมเงื่อนไขสำหรับการใช้งานในหลายกฎ

service ประกอบด้วยบล็อกการ match อย่างน้อยหนึ่ง match พร้อมคำสั่ง allow ที่ให้เงื่อนไขในการเข้าถึงคำขอ ตัวแปร request และ resource พร้อมใช้งานในเงื่อนไขของกฎ ภาษากฎความปลอดภัยของ Firebase ยังรองรับ function ประกาศ function

เวอร์ชันไวยากรณ์

คำสั่ง syntax ระบุเวอร์ชันของภาษากฎ Firebase ที่ใช้เขียนซอร์ส เวอร์ชันล่าสุดของภาษาคือ v2

rules_version = '2';
service cloud.firestore {
...
}

หากไม่มีการระบุคำสั่ง rules_version กฎของคุณจะได้รับการประเมินโดยใช้เครื่องมือ v1

บริการ

การประกาศ service กำหนดผลิตภัณฑ์หรือบริการ Firebase ที่กฎของคุณใช้กับ คุณสามารถรวมการประกาศ service เพียงรายการเดียวต่อไฟล์ต้นฉบับ

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

การจัดเก็บเมฆ

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

หากคุณกำลังกำหนดกฎสำหรับทั้ง Cloud Firestore และ Cloud Storage โดยใช้ Firebase CLI คุณจะต้องเก็บรักษากฎเหล่านี้ไว้ในไฟล์แยกกัน

การจับคู่

บล็อกการ match ประกาศรูปแบบ path ที่จับคู่กับเส้นทางสำหรับการดำเนินการที่ร้องขอ ( request.path เข้ามา) เนื้อหาของการ match ต้องมีบล็อกการ match แบบซ้อนกันอย่างน้อยหนึ่งบล็อก allow คำสั่งหรือ function ประกาศ function เส้นทางในบล็อกการ match ซ้อนกันจะสัมพันธ์กับเส้นทางในบล็อกการ match หลัก

รูปแบบ path เป็นชื่อที่เหมือนไดเร็กทอรีซึ่งอาจมีตัวแปรหรือสัญลักษณ์แทน รูปแบบ path ช่วยให้สามารถจับคู่เซ็กเมนต์ทางเดียวและหลายเส้นทางได้ ตัวแปรใด ๆ ที่ถูกผูกไว้ใน path จะมองเห็นได้ภายในขอบเขตการ match หรือขอบเขตที่ซ้อนกันใด ๆ ที่มีการประกาศ path

การจับคู่กับรูปแบบ path อาจเป็นเพียงบางส่วนหรือทั้งหมด:

  • การจับคู่บางส่วน: รูปแบบ path เป็นการจับคู่คำนำหน้าของ request.path
  • การจับคู่แบบสมบูรณ์: รูปแบบ path ตรงกับ request.path ทั้งหมด

เมื่อ ทำการ จับคู่ เสร็จสมบูรณ์ กฎภายในบล็อกจะได้รับการประเมิน เมื่อทำการจับคู่ บางส่วน กฎการ match แบบซ้อนจะได้รับการทดสอบเพื่อดูว่า path ซ้อนกันจะ ทำให้ การจับคู่ สมบูรณ์ หรือไม่

กฎในการ match สมบูรณ์ แต่ละ match จะได้รับการประเมินเพื่อพิจารณาว่าจะอนุญาตคำขอหรือไม่ หากกฎที่ตรงกันใด ๆ ให้สิทธิ์การเข้าถึงคำขอจะได้รับอนุญาต หากไม่มีกฎที่ตรงกันให้สิทธิ์การเข้าถึงคำขอจะถูกปฏิเสธ

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

ดังตัวอย่างด้านบนการประกาศ path รองรับตัวแปรต่อไปนี้:

  • สัญลักษณ์ตัวแทนเดียว: ตัวแปรตัวแทนถูกประกาศในเส้นทางโดยการรวมตัวแปรไว้ในวงเล็บปีกกา: {variable} ตัวแปรนี้สามารถเข้าถึงได้ภายในคำสั่ง match เป็น string
  • อักขระตัวแทน แบบเรียกซ้ำ : อักขระตัวแทน แบบเรียกซ้ำหรือหลายส่วนจะจับคู่ส่วนเส้นทางหลายส่วนที่หรือด้านล่างเส้นทาง สัญลักษณ์แทนนี้จะจับคู่เส้นทางทั้งหมดด้านล่างตำแหน่งที่คุณตั้งไว้ คุณสามารถประกาศได้โดยเพิ่มสตริง =** ที่ท้ายตัวแปรเซ็กเมนต์ของคุณ: {variable=**} ตัวแปรนี้สามารถเข้าถึงได้ภายในคำสั่งการ match เป็นวัตถุ path

อนุญาต

บล็อกการ match ประกอบด้วยข้อความ allow อย่างน้อยหนึ่งรายการ นี่คือกฎที่แท้จริงของคุณ คุณสามารถใช้กฎการ allow กับวิธีการหนึ่งหรือหลายวิธีได้ เงื่อนไขในคำสั่ง allow ต้องประเมินเป็นจริงสำหรับ Cloud Firestore หรือ Cloud Storage เพื่อให้สิทธิ์คำขอที่เข้ามา คุณยังสามารถเขียนคำสั่ง allow โดยไม่มีเงื่อนไขเช่น allow read อย่างไรก็ตามหากคำสั่ง allow ไม่มีเงื่อนไขก็จะอนุญาตให้มีการร้องขอสำหรับวิธีการนั้นเสมอ

หากเป็นไปตามกฎการ allow สำหรับวิธีการใด ๆ ก็จะได้รับอนุญาต นอกจากนี้หากกฎที่กว้างกว่าให้การเข้าถึงกฎจะให้สิทธิ์เข้าถึงและละเว้นกฎที่ละเอียดกว่าใด ๆ ที่อาจ จำกัด การเข้าถึง

ลองพิจารณาตัวอย่างต่อไปนี้ซึ่งผู้ใช้สามารถอ่านหรือลบไฟล์ของตนเองได้ กฎที่ละเอียดกว่านี้อนุญาตให้เขียนได้ก็ต่อเมื่อผู้ใช้ที่ร้องขอการเขียนเป็นเจ้าของไฟล์และไฟล์นั้นเป็น PNG ผู้ใช้สามารถลบไฟล์ใดก็ได้ในเส้นทางย่อยแม้ว่าจะไม่ใช่ PNG ก็ตามเพราะกฎก่อนหน้านี้อนุญาต

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

วิธี

คำสั่ง allow แต่ละคำสั่งมีวิธีการที่ให้สิทธิ์การเข้าถึงสำหรับคำร้องขอที่เข้ามาของวิธีการเดียวกัน

วิธี ประเภทของคำขอ
วิธีการอำนวยความสะดวก
read คำขออ่านทุกประเภท
write คำขอเขียนทุกประเภท
วิธีมาตรฐาน
get อ่านคำขอเอกสารหรือไฟล์เดียว
list อ่านคำขอสำหรับแบบสอบถามและคอลเล็กชัน
create เขียนเอกสารหรือไฟล์ใหม่
update เขียนลงในเอกสารหรือไฟล์ที่มีอยู่
delete ลบข้อมูล

คุณไม่สามารถซ้อนเมธอดการอ่านในบล็อกการ match เดียวกันหรือวิธีการเขียนที่ขัดแย้งกันในการประกาศ path เดียวกัน

ตัวอย่างเช่นกฎต่อไปนี้จะล้มเหลว:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ฟังก์ชัน

เนื่องจากกฎความปลอดภัยของคุณมีความซับซ้อนมากขึ้นคุณอาจต้องการรวมชุดเงื่อนไขในฟังก์ชันที่คุณสามารถใช้ซ้ำได้ในชุดกฎของคุณ กฎความปลอดภัยรองรับฟังก์ชันที่กำหนดเอง ไวยากรณ์สำหรับฟังก์ชันที่กำหนดเองนั้นคล้ายกับ JavaScript เล็กน้อย แต่ฟังก์ชันกฎความปลอดภัยจะเขียนด้วยภาษาเฉพาะโดเมนซึ่งมีข้อ จำกัด ที่สำคัญบางประการ:

  • ฟังก์ชันสามารถมีคำสั่ง return เพียงรายการเดียว พวกเขาไม่สามารถมีตรรกะเพิ่มเติมใด ๆ ตัวอย่างเช่นไม่สามารถดำเนินการลูปหรือเรียกใช้บริการภายนอกได้
  • ฟังก์ชันสามารถเข้าถึงฟังก์ชันและตัวแปรโดยอัตโนมัติจากขอบเขตที่กำหนดไว้ ตัวอย่างเช่นฟังก์ชันที่กำหนดภายในขอบเขต service cloud.firestore มีการเข้าถึงตัวแปร resource และฟังก์ชันในตัวเช่น get() และ exists()
  • ฟังก์ชันอาจเรียกใช้ฟังก์ชันอื่น ๆ แต่อาจไม่เรียกคืน ความลึกสแต็กการโทรทั้งหมดถูก จำกัด ไว้ที่ 20
  • ในกฎเวอร์ชัน v2 ฟังก์ชันสามารถกำหนดตัวแปรโดยใช้คีย์เวิร์ด let ฟังก์ชันสามารถมีการโยง let ได้สูงสุด 10 รายการ แต่ต้องลงท้ายด้วยคำสั่ง return

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

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

นี่คือตัวอย่างที่แสดงอาร์กิวเมนต์ของฟังก์ชันและอนุญาตให้กำหนด ให้คำสั่งมอบหมายต้องคั่นด้วยเซมิไฟนอล

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

สังเกตว่าการกำหนด isAdmin บังคับใช้การค้นหาคอลเล็กชันผู้ดูแลระบบอย่างไร สำหรับการประเมินแบบขี้เกียจโดยไม่ต้องใช้การค้นหาโดยไม่จำเป็นให้ใช้ประโยชน์จากลักษณะการลัดวงจรของ && (AND) และ || (OR) การเปรียบเทียบเพื่อเรียกใช้ฟังก์ชันที่สองก็ต่อเมื่อ isAuthor แสดงว่าเป็นจริง (สำหรับการเปรียบเทียบ && ) หรือเท็จ (สำหรับ || การเปรียบเทียบ)

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

การใช้ฟังก์ชันในกฎความปลอดภัยของคุณทำให้สามารถดูแลรักษาได้มากขึ้นเมื่อความซับซ้อนของกฎของคุณเพิ่มขึ้น

การจัดเก็บเมฆ

องค์ประกอบพื้นฐานของกฎใน Cloud Firestore และ Cloud Storage มีดังนี้:

  • การประกาศ service : ประกาศผลิตภัณฑ์ Firebase ที่กฎบังคับใช้
  • บล็อกการ match : กำหนดเส้นทางในฐานข้อมูลหรือที่เก็บข้อมูลที่ใช้กับกฎ
  • คำสั่ง allow : ให้เงื่อนไขในการให้สิทธิ์เข้าถึงโดยแยกตามวิธีการ วิธีการที่รองรับ ได้แก่ get , list , create , update , delete และวิธีการอำนวยความสะดวกในการ read และ write
  • function ประกาศ function เสริม: ให้ความสามารถในการรวมและรวมเงื่อนไขสำหรับการใช้งานในหลายกฎ

service ประกอบด้วยบล็อกการ match อย่างน้อยหนึ่ง match พร้อมคำสั่ง allow ที่ให้เงื่อนไขในการเข้าถึงคำขอ ตัวแปร request และ resource พร้อมใช้งานในเงื่อนไขของกฎ ภาษากฎความปลอดภัยของ Firebase ยังรองรับ function ประกาศ function

เวอร์ชันไวยากรณ์

คำสั่ง syntax ระบุเวอร์ชันของภาษากฎ Firebase ที่ใช้เขียนซอร์ส เวอร์ชันล่าสุดของภาษาคือ v2

rules_version = '2';
service cloud.firestore {
...
}

หากไม่มีการระบุคำสั่ง rules_version กฎของคุณจะได้รับการประเมินโดยใช้เครื่องมือ v1

บริการ

การประกาศ service กำหนดผลิตภัณฑ์หรือบริการ Firebase ที่กฎของคุณใช้กับ คุณสามารถรวมการประกาศ service เพียงรายการเดียวต่อไฟล์ต้นฉบับ

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

การจัดเก็บเมฆ

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

หากคุณกำลังกำหนดกฎสำหรับทั้ง Cloud Firestore และ Cloud Storage โดยใช้ Firebase CLI คุณจะต้องเก็บรักษากฎเหล่านี้ไว้ในไฟล์แยกกัน

การจับคู่

บล็อกการ match ประกาศรูปแบบ path ที่จับคู่กับเส้นทางสำหรับการดำเนินการที่ร้องขอ ( request.path เข้ามา) เนื้อหาของการ match ต้องมีบล็อกการ match แบบซ้อนกันอย่างน้อยหนึ่งบล็อก allow คำสั่งหรือ function ประกาศ function เส้นทางในบล็อกการ match ซ้อนกันจะสัมพันธ์กับเส้นทางในบล็อกการ match หลัก

รูปแบบ path คือชื่อที่เหมือนไดเร็กทอรีซึ่งอาจมีตัวแปรหรือสัญลักษณ์แทน รูปแบบ path ช่วยให้สามารถจับคู่เซ็กเมนต์ทางเดียวและหลายเส้นทางได้ ตัวแปรใด ๆ ที่ถูกผูกไว้ใน path จะมองเห็นได้ภายในขอบเขตการ match หรือขอบเขตที่ซ้อนกันใด ๆ ที่มีการประกาศ path

การจับคู่กับรูปแบบ path อาจเป็นเพียงบางส่วนหรือทั้งหมด:

  • การจับคู่บางส่วน: รูปแบบ path เป็นการจับคู่คำนำหน้าของ request.path
  • การจับคู่แบบสมบูรณ์: รูปแบบ path ตรงกับ request.path ทั้งหมด

เมื่อ ทำการ จับคู่ เสร็จสมบูรณ์ กฎภายในบล็อกจะได้รับการประเมิน เมื่อมี การ จับคู่ บางส่วน กฎการ match แบบซ้อนจะได้รับการทดสอบเพื่อดูว่า path ซ้อนกันจะ ทำให้ การจับคู่ สมบูรณ์ หรือไม่

กฎในการ match สมบูรณ์ แต่ละ match จะได้รับการประเมินเพื่อพิจารณาว่าจะอนุญาตคำขอหรือไม่ หากกฎที่ตรงกันใด ๆ ให้สิทธิ์การเข้าถึงคำขอจะได้รับอนุญาต หากไม่มีกฎที่ตรงกันให้สิทธิ์การเข้าถึงคำขอจะถูกปฏิเสธ

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

ดังตัวอย่างด้านบนการประกาศ path รองรับตัวแปรต่อไปนี้:

  • สัญลักษณ์ตัวแทนกลุ่มเดียว: ตัวแปรตัวแทนถูกประกาศในเส้นทางโดยการรวมตัวแปรไว้ในวงเล็บปีกกา: {variable} ตัวแปรนี้สามารถเข้าถึงได้ภายในคำสั่ง match เป็น string
  • อักขระตัวแทน แบบเรียกซ้ำ : อักขระตัวแทน แบบเรียกซ้ำหรือหลายส่วนจะจับคู่ส่วนเส้นทางหลายส่วนที่หรือด้านล่างเส้นทาง สัญลักษณ์แทนนี้จะจับคู่เส้นทางทั้งหมดด้านล่างตำแหน่งที่คุณตั้งไว้ คุณสามารถประกาศได้โดยเพิ่มสตริง =** ที่ท้ายตัวแปรเซ็กเมนต์ของคุณ: {variable=**} ตัวแปรนี้สามารถเข้าถึงได้ภายในคำสั่งการ match เป็นวัตถุ path

อนุญาต

บล็อกการ match ประกอบด้วยข้อความ allow อย่างน้อยหนึ่งรายการ นี่คือกฎที่แท้จริงของคุณ คุณสามารถใช้กฎการ allow กับวิธีการหนึ่งหรือหลายวิธีได้ เงื่อนไขในคำสั่ง allow ต้องประเมินเป็นจริงสำหรับ Cloud Firestore หรือ Cloud Storage เพื่อให้สิทธิ์คำขอที่เข้ามา คุณยังสามารถเขียนคำสั่ง allow โดยไม่มีเงื่อนไขเช่น allow read อย่างไรก็ตามหากคำสั่ง allow ไม่มีเงื่อนไขก็จะอนุญาตให้มีการร้องขอสำหรับวิธีการนั้นเสมอ

หากเป็นไปตามกฎการ allow สำหรับวิธีการใด ๆ ก็จะได้รับอนุญาต นอกจากนี้หากกฎที่กว้างกว่าให้การเข้าถึงกฎจะให้สิทธิ์เข้าถึงและละเว้นกฎที่ละเอียดกว่าใด ๆ ที่อาจ จำกัด การเข้าถึง

ลองพิจารณาตัวอย่างต่อไปนี้ซึ่งผู้ใช้สามารถอ่านหรือลบไฟล์ของตนเองได้ กฎที่ละเอียดกว่านี้อนุญาตให้เขียนได้ก็ต่อเมื่อผู้ใช้ที่ร้องขอการเขียนเป็นเจ้าของไฟล์และไฟล์นั้นเป็น PNG ผู้ใช้สามารถลบไฟล์ใดก็ได้ในเส้นทางย่อยแม้ว่าจะไม่ใช่ PNG ก็ตามเพราะกฎก่อนหน้านี้อนุญาต

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

วิธี

คำสั่ง allow แต่ละคำสั่งมีวิธีการที่ให้สิทธิ์การเข้าถึงสำหรับคำร้องขอที่เข้ามาของวิธีการเดียวกัน

วิธี ประเภทของคำขอ
วิธีการอำนวยความสะดวก
read คำขออ่านทุกประเภท
write คำขอเขียนทุกประเภท
วิธีการมาตรฐาน
get อ่านคำขอเอกสารหรือไฟล์เดียว
list อ่านคำขอสำหรับแบบสอบถามและคอลเล็กชัน
create เขียนเอกสารหรือไฟล์ใหม่
update เขียนลงในเอกสารหรือไฟล์ที่มีอยู่
delete ลบข้อมูล

คุณไม่สามารถซ้อนเมธอดการอ่านในบล็อกการ match เดียวกันหรือวิธีการเขียนที่ขัดแย้งกันในการประกาศ path เดียวกัน

ตัวอย่างเช่นกฎต่อไปนี้จะล้มเหลว:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ฟังก์ชัน

เนื่องจากกฎความปลอดภัยของคุณมีความซับซ้อนมากขึ้นคุณอาจต้องการรวมชุดเงื่อนไขในฟังก์ชันที่คุณสามารถใช้ซ้ำได้ในชุดกฎของคุณ กฎความปลอดภัยรองรับฟังก์ชันที่กำหนดเอง ไวยากรณ์สำหรับฟังก์ชันที่กำหนดเองนั้นคล้ายกับ JavaScript เล็กน้อย แต่ฟังก์ชันกฎความปลอดภัยเขียนด้วยภาษาเฉพาะโดเมนซึ่งมีข้อ จำกัด ที่สำคัญบางประการ:

  • ฟังก์ชันสามารถมีคำสั่ง return เพียงรายการเดียว พวกเขาไม่สามารถมีตรรกะเพิ่มเติมใด ๆ ตัวอย่างเช่นไม่สามารถดำเนินการลูปหรือเรียกใช้บริการภายนอกได้
  • ฟังก์ชันสามารถเข้าถึงฟังก์ชันและตัวแปรโดยอัตโนมัติจากขอบเขตที่กำหนดไว้ ตัวอย่างเช่นฟังก์ชันที่กำหนดภายในขอบเขต service cloud.firestore มีการเข้าถึงตัวแปร resource และฟังก์ชันในตัวเช่น get() และ exists()
  • ฟังก์ชันอาจเรียกใช้ฟังก์ชันอื่น ๆ แต่อาจไม่เรียกคืน ความลึกสแต็กการโทรทั้งหมดถูก จำกัด ไว้ที่ 20
  • ในกฎเวอร์ชัน v2 ฟังก์ชันสามารถกำหนดตัวแปรโดยใช้คีย์เวิร์ด let ฟังก์ชันสามารถมีการโยง let ได้สูงสุด 10 รายการ แต่ต้องลงท้ายด้วยคำสั่ง return

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

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

นี่คือตัวอย่างที่แสดงอาร์กิวเมนต์ของฟังก์ชันและอนุญาตให้กำหนด ให้คำสั่งมอบหมายต้องคั่นด้วยเซมิไฟนอล

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

สังเกตว่าการกำหนด isAdmin บังคับใช้การค้นหาคอลเล็กชันผู้ดูแลระบบอย่างไร สำหรับการประเมินแบบขี้เกียจโดยไม่ต้องใช้การค้นหาโดยไม่จำเป็นให้ใช้ประโยชน์จากลักษณะการลัดวงจรของ && (AND) และ || (OR) การเปรียบเทียบเพื่อเรียกใช้ฟังก์ชันที่สองก็ต่อเมื่อ isAuthor แสดงว่าเป็นจริง (สำหรับการเปรียบเทียบ && ) หรือเท็จ (สำหรับ || การเปรียบเทียบ)

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

การใช้ฟังก์ชันในกฎความปลอดภัยของคุณทำให้สามารถดูแลรักษาได้มากขึ้นเมื่อความซับซ้อนของกฎของคุณเพิ่มขึ้น

ฐานข้อมูลเรียลไทม์

ตามที่ระบุไว้ข้างต้นกฎฐานข้อมูลแบบเรียลไทม์ประกอบด้วยองค์ประกอบพื้นฐานสามประการ ได้แก่ ตำแหน่งฐานข้อมูลเป็นมิเรอร์ของโครงสร้าง JSON ของฐานข้อมูลประเภทคำขอและเงื่อนไขที่อนุญาตให้เข้าถึง

ที่ตั้งฐานข้อมูล

โครงสร้างของกฎของคุณควรเป็นไปตามโครงสร้างของข้อมูลที่คุณเก็บไว้ในฐานข้อมูลของคุณ ตัวอย่างเช่นในแอปแชทที่มีรายการข้อความคุณอาจมีข้อมูลที่มีลักษณะดังนี้:

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

กฎของคุณควรสะท้อนโครงสร้างนั้น ตัวอย่างเช่น:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

ดังตัวอย่างข้างต้นแสดงให้เห็นกฎฐานข้อมูลแบบเรียลไทม์สนับสนุนตัวแปร $location เพื่อจับคู่ส่วนเส้นทาง ใช้คำนำหน้า $ หน้าส่วนเส้นทางของคุณเพื่อจับคู่กฎของคุณกับโหนดลูกใด ๆ ตามเส้นทาง

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

คุณยังสามารถใช้ $variable ควบคู่ไปกับชื่อพา ธ คงที่

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }

วิธี

ในฐานข้อมูลเรียลไทม์มีกฎสามประเภท กฎสองประเภทนี้ - read และ write - ใช้กับวิธีการของคำขอที่เข้ามา ประเภทกฎการ validate บังคับใช้โครงสร้างข้อมูลและตรวจสอบความถูกต้องของรูปแบบและเนื้อหาของข้อมูล กฎการเรียกใช้ .validate กฎหลังจากการตรวจสอบว่า .write กฎถือเป็นการเข้าถึง

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

ตามค่าเริ่มต้นหากไม่มีกฎอนุญาตการเข้าถึงเส้นทางจะถูกปฏิเสธ

สภาพอาคาร

Cloud Firestore

เงื่อนไขคือนิพจน์บูลีนที่กำหนดว่าควรอนุญาตหรือปฏิเสธการดำเนินการเฉพาะ ตัวแปรการ request และ resource จัดเตรียมบริบทสำหรับเงื่อนไขเหล่านั้น

ตัวแปรการ request

ตัวแปรการ request ประกอบด้วยฟิลด์ต่อไปนี้และข้อมูลที่เกี่ยวข้อง:

request.auth

JSON Web Token (JWT) ที่มีข้อมูลรับรองการตรวจสอบสิทธิ์จาก Firebase Authentication auth โทเค็นมีชุดของการเรียกร้องมาตรฐานและการเรียกร้องที่กำหนดเองที่คุณสร้างขึ้นผ่านการรับรองความถูกต้อง Firebase เรียนรู้เพิ่มเติมเกี่ยวกับ กฎความปลอดภัยและการตรวจสอบสิทธิ์ของ Firebase

request.method

request.method อาจเป็นวิธีมาตรฐานหรือวิธีการที่กำหนดเองก็ได้ นอกจากนี้ยังมีวิธีการอำนวยความสะดวกในการ read และ write เพื่อลดความซับซ้อนของกฎการเขียนที่ใช้กับวิธีมาตรฐานแบบอ่านอย่างเดียวหรือแบบเขียนอย่างเดียวทั้งหมดตามลำดับ

request.params

request.params ประกอบด้วยข้อมูลใด ๆ ที่ไม่เกี่ยวข้องโดยเฉพาะกับ request.resource ที่อาจเป็นประโยชน์สำหรับการประเมิน ในทางปฏิบัติแผนที่นี้ควรว่างเปล่าสำหรับวิธีการมาตรฐานทั้งหมดและควรมีข้อมูลที่ไม่ใช่ทรัพยากรสำหรับวิธีการที่กำหนดเอง บริการต้องระวังอย่าเปลี่ยนชื่อหรือแก้ไขประเภทของคีย์และค่าใด ๆ ที่แสดงเป็นพารามิเตอร์

request.path

request.path คือพา ธ สำหรับ resource เป้าหมาย เส้นทางสัมพันธ์กับบริการ ส่วนเส้นทางที่มีอักขระปลอดภัยที่ไม่ใช่ URL เช่น / มีการเข้ารหัส URL

ตัวแปร resource

resource คือค่าปัจจุบันภายในบริการที่แสดงเป็นแผนที่ของคู่คีย์ - ค่า การอ้างอิง resource ภายในเงื่อนไขจะส่งผลให้มีการอ่านค่าจากบริการมากที่สุด การค้นหานี้จะนับรวมกับโควต้าที่เกี่ยวข้องกับบริการสำหรับทรัพยากร สำหรับการ get การร้องขอที่ resource จะนับรวมโควต้าในการปฏิเสธ

ตัวดำเนินการและลำดับความสำคัญของตัวดำเนินการ

ใช้ตารางด้านล่างเป็นข้อมูลอ้างอิงสำหรับตัวดำเนินการและลำดับความสำคัญที่สอดคล้องกันในกฎสำหรับ Cloud Firestore และ Cloud Storage

กำหนดนิพจน์โดยพลการ a และ b ฟิลด์ f และดัชนี i

โอเปอเรเตอร์ คำอธิบาย ความสัมพันธ์
a[i] a() af ดัชนีการโทรการเข้าถึงฟิลด์ จากซ้ายไปขวา
!a -a การปฏิเสธ Unary จากขวาไปซ้าย
a/ba%ba*b ตัวดำเนินการหลายหลาก จากซ้ายไปขวา
a+b ab ตัวดำเนินการเพิ่มเติม จากซ้ายไปขวา
a>b a>=b a<b a<=b ตัวดำเนินการเชิงสัมพันธ์ จากซ้ายไปขวา
a in b , a is b การมีอยู่ในรายการหรือแผนที่การเปรียบเทียบประเภท จากซ้ายไปขวา
a==ba!=b ตัวดำเนินการเปรียบเทียบ จากซ้ายไปขวา
a && b เงื่อนไขและ จากซ้ายไปขวา
a || b เงื่อนไขหรือ จากซ้ายไปขวา
a ? true_value : false_value นิพจน์ Ternary จากซ้ายไปขวา

การจัดเก็บเมฆ

เงื่อนไขคือนิพจน์บูลีนที่กำหนดว่าควรอนุญาตหรือปฏิเสธการดำเนินการเฉพาะ ตัวแปรการ request และ resource จัดเตรียมบริบทสำหรับเงื่อนไขเหล่านั้น

ตัวแปรการ request

ตัวแปรการ request ประกอบด้วยฟิลด์ต่อไปนี้และข้อมูลที่เกี่ยวข้อง:

request.auth

JSON Web Token (JWT) ที่มีข้อมูลรับรองการตรวจสอบสิทธิ์จาก Firebase Authentication auth โทเค็นมีชุดของการเรียกร้องมาตรฐานและการเรียกร้องที่กำหนดเองที่คุณสร้างขึ้นผ่านการรับรองความถูกต้อง Firebase เรียนรู้เพิ่มเติมเกี่ยวกับ กฎความปลอดภัยและการตรวจสอบสิทธิ์ของ Firebase

request.method

request.method อาจเป็นวิธีมาตรฐานหรือวิธีการแบบกำหนดเองก็ได้ นอกจากนี้ยังมีวิธีการอำนวยความสะดวกในการ read และ write เพื่อลดความซับซ้อนของกฎการเขียนที่ใช้กับวิธีมาตรฐานแบบอ่านอย่างเดียวหรือแบบเขียนอย่างเดียวทั้งหมดตามลำดับ

request.params

request.params ประกอบด้วยข้อมูลใด ๆ ที่ไม่เกี่ยวข้องโดยเฉพาะกับ request.resource ที่อาจเป็นประโยชน์สำหรับการประเมิน ในทางปฏิบัติแผนที่นี้ควรว่างเปล่าสำหรับวิธีการมาตรฐานทั้งหมดและควรมีข้อมูลที่ไม่ใช่ทรัพยากรสำหรับวิธีการที่กำหนดเอง บริการต้องระวังอย่าเปลี่ยนชื่อหรือแก้ไขประเภทของคีย์และค่าใด ๆ ที่แสดงเป็นพารามิเตอร์

request.path

request.path คือพา ธ สำหรับ resource เป้าหมาย เส้นทางสัมพันธ์กับบริการ ส่วนเส้นทางที่มีอักขระปลอดภัยที่ไม่ใช่ URL เช่น / มีการเข้ารหัส URL

ตัวแปร resource

resource คือค่าปัจจุบันภายในบริการที่แสดงเป็นแผนที่ของคู่คีย์ - ค่า การอ้างอิง resource ภายในเงื่อนไขจะส่งผลให้มีการอ่านค่าจากบริการมากที่สุด การค้นหานี้จะนับรวมกับโควต้าที่เกี่ยวข้องกับบริการสำหรับทรัพยากร สำหรับการ get การร้องขอที่ resource จะนับรวมโควต้าในการปฏิเสธ

ตัวดำเนินการและลำดับความสำคัญของตัวดำเนินการ

ใช้ตารางด้านล่างเป็นข้อมูลอ้างอิงสำหรับตัวดำเนินการและลำดับความสำคัญที่สอดคล้องกันในกฎสำหรับ Cloud Firestore และ Cloud Storage

กำหนดนิพจน์โดยพลการ a และ b ฟิลด์ f และดัชนี i

โอเปอเรเตอร์ คำอธิบาย ความสัมพันธ์
a[i] a() af ดัชนีการโทรการเข้าถึงฟิลด์ จากซ้ายไปขวา
!a -a การปฏิเสธ Unary จากขวาไปซ้าย
a/ba%ba*b ตัวดำเนินการหลายหลาก จากซ้ายไปขวา
a+b ab ตัวดำเนินการเพิ่มเติม จากซ้ายไปขวา
a>b a>=b a<b a<=b ตัวดำเนินการเชิงสัมพันธ์ จากซ้ายไปขวา
a in b , a is b การมีอยู่ในรายการหรือแผนที่การเปรียบเทียบประเภท จากซ้ายไปขวา
a==ba!=b ตัวดำเนินการเปรียบเทียบ จากซ้ายไปขวา
a && b เงื่อนไขและ จากซ้ายไปขวา
a || b เงื่อนไขหรือ จากซ้ายไปขวา
a ? true_value : false_value นิพจน์ Ternary จากซ้ายไปขวา

ฐานข้อมูลเรียลไทม์

เงื่อนไขคือนิพจน์บูลีนที่กำหนดว่าควรอนุญาตหรือปฏิเสธการดำเนินการเฉพาะ คุณสามารถกำหนดเงื่อนไขเหล่านั้นในกฎฐานข้อมูลแบบเรียลไทม์ได้ด้วยวิธีต่อไปนี้

ตัวแปรที่กำหนดไว้ล่วงหน้า

มีตัวแปรที่กำหนดไว้ล่วงหน้าที่เป็นประโยชน์จำนวนหนึ่งซึ่งสามารถเข้าถึงได้ภายในข้อกำหนดของกฎ สรุปสั้น ๆ ของแต่ละข้อมีดังนี้

ตัวแปรที่กำหนดไว้ล่วงหน้า
ตอนนี้ เวลาปัจจุบันในหน่วยมิลลิวินาทีนับตั้งแต่ยุคลินุกซ์ สิ่งนี้ใช้ได้ดีโดยเฉพาะอย่างยิ่งสำหรับการตรวจสอบการประทับเวลาที่สร้างด้วย firebase.database.ServerValue.TIMESTAMP ของ SDK
ราก RuleDataSnapshot แสดงถึงเส้นทางรากในฐานข้อมูล Firebase ตามที่มีอยู่ก่อนการดำเนินการที่พยายาม
newData RuleDataSnapshot แสดงข้อมูลตามที่จะมีอยู่หลังจากการดำเนินการที่พยายาม ซึ่งรวมถึงข้อมูลใหม่ที่กำลังเขียนและข้อมูลที่มีอยู่
ข้อมูล RuleDataSnapshot แสดงข้อมูลตามที่มีอยู่ก่อนการดำเนินการที่พยายาม
ตัวแปร $ เส้นทางตัวแทนที่ใช้แทนรหัสและคีย์ลูกแบบไดนามิก
รับรองความถูกต้อง แสดงเพย์โหลดโทเค็นของผู้ใช้ที่พิสูจน์ตัวตน

ตัวแปรเหล่านี้สามารถใช้ได้ทุกที่ในกฎของคุณ ตัวอย่างเช่นกฎความปลอดภัยด้านล่างตรวจสอบให้แน่ใจว่าข้อมูลที่เขียนไปยัง /foo/ node ต้องเป็นสตริงที่น้อยกว่า 100 อักขระ:

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

กฎที่อิงข้อมูล

ข้อมูลใด ๆ ในฐานข้อมูลของคุณสามารถใช้ในกฎของคุณได้ การใช้ root data และ newData ตัวแปรที่กำหนดไว้ล่วงหน้าคุณสามารถเข้าถึงเส้นทางใดก็ได้ตามที่มีอยู่ก่อนหรือหลังเหตุการณ์การเขียน

พิจารณาตัวอย่างนี้ซึ่งอนุญาตให้เขียนได้ตราบเท่าที่ค่าของ /allow_writes/ node เป็น true โหนดพาเรนต์ไม่มีชุดแฟ readOnly และมีชายด์ชื่อ foo ในข้อมูลที่เขียนใหม่:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

กฎตามการสืบค้น

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

ตัวอย่างเช่นกฎตามแบบสอบถามต่อไปนี้ใช้กฎ การรักษาความปลอดภัยที่อิงตามผู้ใช้ และ กฎ ตามคิวรีเพื่อ จำกัด การเข้าถึงข้อมูลในคอลเลกชัน baskets เฉพาะตะกร้าสินค้าที่ผู้ใช้ที่ใช้งานอยู่เป็นเจ้าของ:

"baskets": {
  ".read": "auth.uid != null &&
            query.orderByChild == 'owner' &&
            query.equalTo == auth.uid" // restrict basket access to owner of basket
}

การสืบค้นต่อไปนี้ซึ่งรวมถึงพารามิเตอร์การค้นหาในกฎจะประสบความสำเร็จ:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

อย่างไรก็ตามแบบสอบถามที่ไม่มีพารามิเตอร์ในกฎจะล้มเหลวด้วยข้อผิดพลาด PermissionDenied :

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

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

ตัวอย่างเช่นกฎต่อไปนี้ จำกัด การเข้าถึงการอ่านเฉพาะผลลัพธ์ 1,000 รายการแรกของแบบสอบถามตามลำดับความสำคัญ:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

query. ต่อไปนี้ นิพจน์มีอยู่ในกฎฐานข้อมูลแบบเรียลไทม์

นิพจน์กฎที่อิงการสืบค้น
นิพจน์ ประเภท คำอธิบาย
query.orderByKey
query.orderByPriority
query.orderByValue
บูลีน เป็นจริงสำหรับการสืบค้นที่เรียงลำดับตามคีย์ลำดับความสำคัญหรือค่า เป็นอย่างอื่นเท็จ
query.orderByChild สตริง
โมฆะ
ใช้สตริงเพื่อแทนพา ธ สัมพัทธ์ไปยังโหนดลูก ตัวอย่างเช่น query.orderByChild == "address/zip" ถ้าโหนดลูกไม่ได้เรียงลำดับคิวรีค่านี้จะเป็นโมฆะ
query.startAt
query.endAt
query.equalTo
สตริง
จำนวน
บูลีน
โมฆะ
ดึงข้อมูลขอบเขตของคิวรีที่ดำเนินการหรือส่งคืนค่าว่างหากไม่มีชุดที่ถูกผูกไว้
query.limitToFirst
query.limitToLast
จำนวน
โมฆะ
ดึงขีด จำกัด ของคิวรีที่ดำเนินการหรือส่งคืนค่าว่างหากไม่มีการตั้งค่าขีด จำกัด

โอเปอเรเตอร์

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

การสร้างเงื่อนไข

เงื่อนไขที่แท้จริงของคุณจะแตกต่างกันไปตามการเข้าถึงที่คุณต้องการให้สิทธิ์ กฎมีเจตนาให้ความยืดหยุ่นในระดับมหาศาลดังนั้นในที่สุดกฎของแอปจะเรียบง่ายหรือซับซ้อนเท่าที่คุณต้องการ

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