เรียนรู้ไวยากรณ์หลักของภาษา Realtime Database Rules

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

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

หัวข้อนี้อธิบายเกี่ยวกับไวยากรณ์และโครงสร้างพื้นฐาน Realtime Database Security Rules ที่ใช้ในการสร้างชุดกฎทั้งหมด

การจัดโครงสร้างกฎความปลอดภัยของคุณ

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

กฎพื้นฐาน ระบุชุดของโหนด ที่จะรักษาความปลอดภัย วิธีการเข้าถึง (เช่นอ่านเขียน) ที่เกี่ยวข้องและ เงื่อนไข ที่อนุญาตหรือปฏิเสธการเข้าถึง ในตัวอย่างต่อไปนี้ เงื่อนไข ของเราจะเป็นข้อความ true และ false อย่างง่าย แต่ในหัวข้อถัดไปเราจะกล่าวถึงวิธีที่มีพลวัตมากขึ้นในการแสดงเงื่อนไข

ตัวอย่างเช่นหากเราพยายามรักษาความปลอดภัย child_node ภายใต้ parent_node ไวยากรณ์ทั่วไปที่จะปฏิบัติตามคือ:

{
  "rules": {
    "parent_node": {
      "child_node": {
        ".read": <condition>,
        ".write": <condition>,
        ".validate": <condition>,
      }
    }
  }
}

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

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

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

{
  "rules": {
    // For requests to access the 'messages' node...
    "messages": {
      // ...and the individual wildcarded 'message' nodes beneath
      // (we'll cover wildcarding variables more a bit later)....
      "$message": {

        // For each message, allow a read operation if <condition>. In this
        // case, we specify our condition as "true", so read access is always granted.
        ".read": "true",

        // For read-only behavior, we specify that for write operations, our
        // condition is false.
        ".write": "false"
      }
    }
  }
}

การดำเนินการตามกฎพื้นฐาน

มีสามประเภทของกฎสำหรับการบังคับใช้การรักษาความปลอดภัยขึ้นอยู่กับชนิดของการดำเนินงานที่มีการดำเนินการเกี่ยวกับข้อมูลที่มี: .write , .read และ .validate นี่คือสรุปโดยย่อเกี่ยวกับวัตถุประสงค์ของพวกเขา:

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

หมายเหตุ: การเข้าถึงไม่ได้รับอนุญาตโดยค่าเริ่มต้น ถ้าไม่มี .write หรือ .read กฎที่ระบุไว้หรือสูงกว่าเส้นทางการเข้าถึงจะถูกปฏิเสธ

ตัวแปรการจับภาพสัญลักษณ์ตัวแทน

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

{
  "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')"
        }
      }
    }
  }
}

ตัวแปร $ แบบไดนามิกยังสามารถใช้ควบคู่กับชื่อพา ธ คงที่ ในตัวอย่างนี้เราใช้ตัวแปร $other เพื่อประกาศกฏ. .validate ที่ทำให้แน่ใจว่า widget ไม่มีลูกอื่นนอกจาก title และ color การเขียนใด ๆ ที่จะส่งผลให้มีการสร้างเด็กเพิ่มเติมจะล้มเหลว

{
  "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 }
    }
  }
}

หมายเหตุ: คีย์พา ธ เป็นสตริงเสมอ ด้วยเหตุนี้สิ่งสำคัญคือต้องจำไว้ว่าเมื่อเราพยายามเปรียบเทียบตัวแปร $ กับตัวเลขสิ่งนี้จะล้มเหลวเสมอ สามารถแก้ไขได้โดยการแปลงตัวเลขเป็นสตริง (เช่น $key === newData.val()+'' )

อ่านและเขียน Cascade กฎ

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

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

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

โครงสร้างการรักษาความปลอดภัยนี้อนุญาตให้ /bar/ สามารถอ่านได้เมื่อใดก็ตามที่ /foo/ มี baz ลูกที่มีค่า true ".read": false กฎ ".read": false ภายใต้ /foo/bar/ ไม่มีผลที่นี่เนื่องจากเส้นทางลูกไม่สามารถเพิกถอนการเข้าถึงได้

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

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

กฎไม่ใช่ตัวกรอง

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

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

หากไม่เข้าใจว่ากฎได้รับการประเมินแบบอะตอมดูเหมือนว่าการดึงข้อมูล /records/ path จะส่งคืน rec1 แต่ไม่ใช่ rec2 อย่างไรก็ตามผลลัพธ์ที่แท้จริงเป็นข้อผิดพลาด:

JavaScript

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

วัตถุประสงค์ -C

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];

รวดเร็ว

var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})

Java

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});

ส่วนที่เหลือ

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

เนื่องจากการดำเนินการอ่านที่ /records/ เป็นอะตอมและไม่มีกฎการอ่านที่อนุญาตให้เข้าถึงข้อมูลทั้งหมดภายใต้ /records/ สิ่งนี้จะทำให้เกิดข้อผิดพลาด PERMISSION_DENIED หากเราประเมินกฎนี้ในโปรแกรมจำลองความปลอดภัยใน คอนโซล Firebase ของเราเราจะเห็นว่าการดำเนินการอ่านถูกปฏิเสธเนื่องจากกฎการอ่านไม่อนุญาตให้เข้าถึง /records/ path อย่างไรก็ตามโปรดทราบว่ากฎสำหรับ rec1 ไม่ได้รับการประเมินเนื่องจากไม่อยู่ในเส้นทางที่เราขอ ในการดึงข้อมูล rec1 เราจำเป็นต้องเข้าถึงโดยตรง:

JavaScript

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

วัตถุประสงค์ -C

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

รวดเร็ว

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

Java

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});

ส่วนที่เหลือ

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

คำสั่งที่ทับซ้อนกัน

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

{
  "rules": {
    "messages": {
      // A rule expression that applies to all nodes in the 'messages' node
      "$message": {
        ".read": "true",
        ".write": "true"
      },
      // A second rule expression applying specifically to the 'message1` node
      "message1": {
        ".read": "false",
        ".write": "false"
      }
    }
  }
}

ในตัวอย่างด้านบนการอ่านไปยังโหนด message1 จะถูกปฏิเสธเนื่องจากกฎข้อที่สองเป็น false เสมอแม้ว่ากฎข้อแรกจะเป็น true เสมอก็ตาม

ขั้นตอนถัดไป

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

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

• ตรวจสอบกรณีการใช้งานด้านความปลอดภัยทั่วไปและ ข้อกำหนดกฎความปลอดภัยของ Firebase ที่ ระบุถึงกรณี ดัง กล่าว