Check out what’s new from Firebase@ Google I/O 2021, and join our alpha program for early access to the new Remote Config personalization feature. Learn more

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

กฎความปลอดภัยของ 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 ช่วงขึ้นไปพร้อมคำสั่ง allow ที่ให้เงื่อนไขในการอนุญาตการเข้าถึงคำขอ ตัวแปร request และ resource พร้อมใช้งานในเงื่อนไขกฎ ภาษากฎความปลอดภัยของ Firebase ยังรองรับ function ประกาศ function ด้วย

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

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

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

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

บริการ

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

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 อย่างน้อย 1 รายการ เส้นทางในบล็อกการ 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 ฟังก์ชันสามารถมีการเชื่อมโยงได้มากถึง 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 บังคับใช้การค้นหาคอลเล็กชันของผู้ดูแลระบบอย่างไร สำหรับการประเมินแบบ Lazy โดยไม่ต้องมีการค้นหาที่ไม่จำเป็น ให้ใช้ประโยชน์จากลักษณะการลัดวงจรของ && (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 ช่วงขึ้นไปพร้อมคำสั่ง allow ที่ให้เงื่อนไขในการอนุญาตการเข้าถึงคำขอ ตัวแปร request และ resource พร้อมใช้งานในเงื่อนไขกฎ ภาษากฎความปลอดภัยของ Firebase ยังรองรับ function ประกาศ function ด้วย

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

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

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

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

บริการ

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

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 อย่างน้อย 1 รายการ เส้นทางในบล็อกการ 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 ฟังก์ชันสามารถมีการเชื่อมโยงได้มากถึง 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 บังคับใช้การค้นหาคอลเล็กชันของผู้ดูแลระบบอย่างไร สำหรับการประเมินแบบ Lazy โดยไม่ต้องใช้การค้นหาที่ไม่จำเป็น ให้ใช้ประโยชน์จากลักษณะการลัดวงจรของ && (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 ปฏิเสธเอกพจน์ จากขวาไปซ้าย
a/ba%ba*b ตัวดำเนินการคูณ ซ้ายไปขวา
a+b ab ตัวดำเนินการเสริม ซ้ายไปขวา
a>ba>=ba ตัวดำเนินการเชิงสัมพันธ์ ซ้ายไปขวา
a in b การมีอยู่ในรายการหรือแผนที่ ซ้ายไปขวา
a is type การเปรียบเทียบประเภท โดยที่ type สามารถเป็น bool, int, float, number, string, list, map, timestamp, Duration, path หรือ latlng ซ้ายไปขวา
a==ba!=b ตัวดำเนินการเปรียบเทียบ ซ้ายไปขวา
a && b เงื่อนไขและ ซ้ายไปขวา
a || b OR . แบบมีเงื่อนไข ซ้ายไปขวา
a ? true_value : false_value นิพจน์ไตรลักษณ์ ซ้ายไปขวา

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

เงื่อนไขคือนิพจน์บูลีนที่กำหนดว่าการดำเนินการเฉพาะควรได้รับอนุญาตหรือปฏิเสธ ตัวแปร 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 ปฏิเสธเอกพจน์ จากขวาไปซ้าย
a/ba%ba*b ตัวดำเนินการคูณ ซ้ายไปขวา
a+b ab ตัวดำเนินการเสริม ซ้ายไปขวา
a>ba>=ba ตัวดำเนินการเชิงสัมพันธ์ ซ้ายไปขวา
a in b การมีอยู่ในรายการหรือแผนที่ ซ้ายไปขวา
a is type การเปรียบเทียบประเภท โดยที่ type สามารถเป็น bool, int, float, number, string, list, map, timestamp, Duration, path หรือ latlng ซ้ายไปขวา
a==ba!=b ตัวดำเนินการเปรียบเทียบ ซ้ายไปขวา
a && b เงื่อนไขและ ซ้ายไปขวา
a || b OR . แบบมีเงื่อนไข ซ้ายไปขวา
a ? true_value : false_value นิพจน์ไตรลักษณ์ ซ้ายไปขวา

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

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

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

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

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

ตัวแปรเหล่านี้สามารถใช้ได้ที่ใดก็ได้ในกฎของคุณ ตัวอย่างเช่น กฎความปลอดภัยด้านล่างช่วยให้มั่นใจว่าข้อมูลที่เขียนไปยังโหนด /foo/ ต้องเป็นสตริงที่น้อยกว่า 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/ เป็น 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
บูลีน True สำหรับการค้นหาที่เรียงลำดับตามคีย์ ลำดับความสำคัญ หรือค่า เท็จเป็นอย่างอื่น
query.orderByChild สตริง
null
ใช้สตริงเพื่อแสดงเส้นทางสัมพันธ์กับโหนดย่อย ตัวอย่างเช่น query.orderByChild == "address/zip" ถ้าการสืบค้นไม่ได้เรียงลำดับโดยโหนดย่อย ค่านี้เป็นค่าว่าง
query.startAt
query.endAt
query.equalTo
สตริง
จำนวน
บูลีน
null
ดึงขอบเขตของคิวรีที่กำลังดำเนินการ หรือคืนค่า null หากไม่มีชุดที่ถูกผูกไว้
query.limitToFirst
query.limitToLast
จำนวน
null
ดึงขีดจำกัดในการเรียกใช้คิวรี หรือส่งกลับค่า null ถ้าไม่มีการกำหนดขีดจำกัด

ผู้ประกอบการ

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

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

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

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