กฎการรักษาความปลอดภัยฐานข้อมูลแบบเรียลไทม์ของ 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 | กำหนดว่าค่าที่จัดรูปแบบถูกต้องจะมีลักษณะอย่างไรไม่ว่าจะมีแอตทริบิวต์ลูกหรือไม่และประเภทข้อมูล |
ตัวแปรการจับภาพสัญลักษณ์ตัวแทน
คำสั่งกฎทั้งหมดชี้ไปที่โหนด คำสั่งสามารถชี้ไปที่โหนดเฉพาะหรือใช้ ตัวแปรการดักจับ $
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 } } } }
อ่านและเขียน 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 ที่ ระบุถึงกรณี ดัง กล่าว