กฎความปลอดภัยของฐานข้อมูลเรียลไทม์ของ Firebase ช่วยให้คุณควบคุมการเข้าถึงข้อมูลที่จัดเก็บไว้ในฐานข้อมูลของคุณ ไวยากรณ์ของกฎที่ยืดหยุ่นช่วยให้คุณสร้างกฎที่ตรงกับอะไรก็ได้ ตั้งแต่การเขียนทั้งหมดไปยังฐานข้อมูลของคุณไปจนถึงการดำเนินการในแต่ละโหนด
กฎความปลอดภัยของฐานข้อมูลแบบเรียลไทม์คือการกำหนดค่า แบบประกาศ สำหรับฐานข้อมูลของคุณ ซึ่งหมายความว่ากฎถูกกำหนดแยกต่างหากจากตรรกะของผลิตภัณฑ์ สิ่งนี้มีข้อดีหลายประการ: ลูกค้าไม่ต้องรับผิดชอบในการบังคับใช้ความปลอดภัย การใช้งานบั๊กกี้จะไม่ทำให้ข้อมูลของคุณเสียหาย และบางทีที่สำคัญที่สุด ไม่จำเป็นต้องมีผู้ตัดสินระดับกลาง เช่น เซิร์ฟเวอร์ เพื่อปกป้องข้อมูลจากโลก
หัวข้อนี้อธิบายไวยากรณ์พื้นฐานและโครงสร้างกฎความปลอดภัยของฐานข้อมูลเรียลไทม์ที่ใช้สร้างชุดกฎที่สมบูรณ์
โครงสร้างกฎความปลอดภัยของคุณ
กฎความปลอดภัยของฐานข้อมูลแบบเรียลไทม์ประกอบด้วยนิพจน์ที่คล้ายกับ 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
นี่คือบทสรุปโดยย่อของวัตถุประสงค์ของพวกเขา:
ประเภทกฎ | |
---|---|
.อ่าน | อธิบายว่าผู้ใช้สามารถอ่านข้อมูลได้หรือไม่และเมื่อใด |
.เขียน | อธิบายว่าอนุญาตให้เขียนข้อมูลได้หรือไม่และเมื่อใด |
.ตรวจสอบความถูกต้อง | กำหนดค่าที่จัดรูปแบบอย่างถูกต้องจะมีลักษณะอย่างไร ไม่ว่าจะมีแอตทริบิวต์ย่อยและประเภทข้อมูลหรือไม่ |
ตัวแปร Wildcard Capture
คำสั่งกฎทั้งหมดชี้ไปที่โหนด คำสั่งสามารถชี้ไปที่โหนดเฉพาะหรือใช้ ตัวแปรดักจับ $
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 } } } }
อ่านและเขียนกฎเรียงซ้อน
กฎ .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
ภายใต้ /foo/bar/
ไม่มีผลที่นี่ เนื่องจากเส้นทางย่อยไม่สามารถเพิกถอนการเข้าถึงได้
แม้ว่าอาจดูเหมือนไม่ง่ายในทันที แต่นี่เป็นส่วนสำคัญของภาษากฎและอนุญาตให้ใช้สิทธิ์การเข้าถึงที่ซับซ้อนมากโดยใช้ความพยายามเพียงเล็กน้อย สิ่งนี้จะแสดงให้เห็นเมื่อเราเข้าสู่การรักษาความปลอดภัยตามผู้ใช้ในภายหลังในคู่มือนี้
โปรดทราบว่ากฎ .validate
จะไม่เรียงซ้อน กฎการตรวจสอบทั้งหมดต้องเป็นไปตามทุกระดับของลำดับชั้นจึงจะอนุญาตให้เขียนได้
กฎไม่ใช่ตัวกรอง
กฎถูกนำไปใช้ในลักษณะปรมาณู ซึ่งหมายความว่าการดำเนินการอ่านหรือเขียนจะล้มเหลวทันทีหากไม่มีกฎในตำแหน่งนั้นหรือตำแหน่งหลักที่ให้สิทธิ์การเข้าถึง แม้ว่าทุกเส้นทางย่อยที่ได้รับผลกระทบจะสามารถเข้าถึงได้ การอ่านที่ตำแหน่งหลักจะล้มเหลวโดยสิ้นเชิง พิจารณาโครงสร้างนี้:
{ "rules": { "records": { "rec1": { ".read": true }, "rec2": { ".read": false } } } }
หากไม่เข้าใจว่ากฎได้รับการประเมินในระดับอะตอม อาจดูเหมือนว่าการดึงข้อมูลเส้นทาง /records/
จะส่งคืน rec1
แต่ไม่ใช่ rec2
อย่างไรก็ตาม ผลลัพธ์ที่แท้จริงคือข้อผิดพลาด:
จาวาสคริปต์
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 })
ชวา
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/
อย่างไรก็ตาม โปรดทราบว่ากฎสำหรับ rec1
ไม่ได้รับการประเมินเนื่องจากไม่ได้อยู่ในเส้นทางที่เราร้องขอ ในการดึง rec1
เราจะต้องเข้าถึงโดยตรง:
จาวาสคริปต์
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! })
ชวา
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 ที่กล่าวถึง