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

กฎความปลอดภัยของ Firebase ใช้ประโยชน์จากภาษาที่ยืดหยุ่น ทรงพลัง และกำหนดเองได้ ซึ่งรองรับความซับซ้อนและความละเอียดที่หลากหลาย คุณสามารถทำให้กฎของคุณเป็นแบบเฉพาะเจาะจงหรือทั่วไปตามความเหมาะสมสำหรับแอปของคุณ กฎฐานข้อมูลเรียลไทม์ใช้ไวยากรณ์ที่ดูเหมือน JavaScript ในโครงสร้าง JSON เมฆ FireStore และการจัดเก็บเมฆกฎการใช้ภาษาที่ขึ้นอยู่กับ การแสดงออกทั่วไปภาษา (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 การประกาศ: ให้ความสามารถในการรวมและห่อเงื่อนไขสำหรับการใช้งานในหลายกฎ

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

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

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

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

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

กฎระเบียบในแต่ละสมบูรณ์ 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 คำสั่งต้องประเมินเป็นจริงสำหรับระบบคลาวด์ FireStore หรือการจัดเก็บเมฆที่จะให้การร้องขอเข้ามา นอกจากนี้คุณยังสามารถเขียน 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 มอบหมายบังคับใช้การค้นหาของคอลเลกชันผู้ดูแลระบบ สำหรับการประเมินผลขี้เกียจโดยไม่ต้องมีการค้นหาที่ไม่จำเป็นใช้ประโยชน์จากธรรมชาติการลัดวงจรของ && (และ) และ || (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 การประกาศ: ให้ความสามารถในการรวมและห่อเงื่อนไขสำหรับการใช้งานในหลายกฎ

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

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

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

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

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

กฎระเบียบในแต่ละสมบูรณ์ 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 คำสั่งต้องประเมินเป็นจริงสำหรับระบบคลาวด์ FireStore หรือการจัดเก็บเมฆที่จะให้การร้องขอเข้ามา นอกจากนี้คุณยังสามารถเขียน 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 มอบหมายบังคับใช้การค้นหาของคอลเลกชันผู้ดูแลระบบ สำหรับการประเมินผลขี้เกียจโดยไม่ต้องมีการค้นหาที่ไม่จำเป็นใช้ประโยชน์จากธรรมชาติการลัดวงจรของ && (และ) และ || (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 กฎถือเป็นการเข้าถึง

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

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

สภาพอาคาร

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

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

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

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

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

สำหรับบางคำแนะนำการสร้างง่ายกฎการผลิตพร้อมดู กฎความปลอดภัยขั้นพื้นฐาน