ใช้เงื่อนไขในกฎฐานข้อมูลเรียลไทม์

คู่มือนี้จะสร้างใน การเรียนรู้หลักภาษา Firebase การรักษาความปลอดภัยกฎ คู่มือจะแสดงวิธีการเพิ่มเงื่อนไขที่คุณ Firebase Realtime ฐานข้อมูลกฎการรักษาความปลอดภัย

กลุ่มอาคารหลักของเรียลไทม์ Database Security กฎเป็นเงื่อนไข เงื่อนไขคือนิพจน์บูลีนที่กำหนดว่าการดำเนินการเฉพาะควรได้รับอนุญาตหรือปฏิเสธ สำหรับกฎพื้นฐานการใช้ true และ false อักษรเป็นเงื่อนไขที่ทำงาน prefectly ดี แต่ภาษากฎการรักษาความปลอดภัยฐานข้อมูลเรียลไทม์ช่วยให้คุณสามารถเขียนเงื่อนไขที่ซับซ้อนมากขึ้นซึ่งสามารถ:

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

การใช้ตัวแปร $ เพื่อจับส่วนเส้นทาง

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

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

การตรวจสอบสิทธิ์

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

หากแอปของคุณใช้การตรวจสอบสิทธิ์ Firebase ที่ request.auth ตัวแปรมีข้อมูลการตรวจสอบข้อมูลลูกค้าร้องขอ สำหรับข้อมูลเพิ่มเติมเกี่ยว request.auth ดู เอกสารอ้างอิง

การตรวจสอบสิทธิ์ของ Firebase ผสานรวมกับฐานข้อมูลเรียลไทม์ของ Firebase เพื่อให้คุณควบคุมการเข้าถึงข้อมูลแบบรายผู้ใช้ได้โดยใช้เงื่อนไข เมื่อพิสูจน์ผู้ใช้ที่ auth ตัวแปรในเรียลไทม์ฐานข้อมูลกฎกฎการรักษาความปลอดภัยของคุณจะมีประชากรที่มีข้อมูลของผู้ใช้ ข้อมูลนี้รวมถึงตัวระบุเอกลักษณ์ของพวกเขา ( uid ) เช่นเดียวกับข้อมูลบัญชีที่เชื่อมโยงเช่น ID Facebook หรือที่อยู่อีเมลและข้อมูลอื่น ๆ หากคุณใช้ผู้ให้บริการตรวจสอบสิทธิ์แบบกำหนดเอง คุณสามารถเพิ่มฟิลด์ของคุณเองลงในเพย์โหลดการตรวจสอบสิทธิ์ของผู้ใช้ได้

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

auth ตัวแปร

กำหนดไว้ล่วงหน้า auth ตัวแปรในกฎระเบียบเป็นโมฆะก่อนที่จะรับรองความถูกต้องเกิดขึ้น

เมื่อผู้ใช้รับรองความถูกต้องมี การตรวจสอบสิทธิ์ Firebase ก็จะมีคุณสมบัติดังต่อไปนี้:

นี่คือกฎตัวอย่างที่ใช้ในการ auth ตัวแปรเพื่อให้มั่นใจว่าผู้ใช้แต่ละคนสามารถเขียนไปยังเส้นทางเฉพาะของผู้ใช้:

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

การจัดโครงสร้างฐานข้อมูลของคุณเพื่อรองรับเงื่อนไขการตรวจสอบสิทธิ์

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

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid"
      }
    }
  }
}

การทำงานกับการอ้างสิทธิ์ที่กำหนดเองสำหรับการตรวจสอบสิทธิ์

สำหรับแอปที่ต้องมีการควบคุมการเข้าถึงที่กำหนดเองสำหรับผู้ใช้ที่แตกต่างกัน Firebase รับรองความถูกต้องช่วยให้นักพัฒนาที่จะ เรียกร้องไว้เมื่อผู้ใช้ Firebase การเรียกร้องเหล่านี้เป็น accesible ใน auth.token ตัวแปรในกฎของคุณ นี่คือตัวอย่างของกฎที่ทำให้การใช้งานที่ hasEmergencyTowel เรียกร้องที่กำหนดเอง:

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

นักพัฒนาสร้าง สัญญาณการตรวจสอบของพวกเขาเอง สามารถเลือกเพิ่มการเรียกร้องที่จะราชสกุลเหล่านี้ การเรียกร้องเหล่านี้เป็น avaialble บน auth.token ตัวแปรในกฎของคุณ

ข้อมูลที่มีอยู่กับข้อมูลใหม่

กำหนดไว้ล่วงหน้า data ตัวแปรที่ใช้ในการอ้างถึงข้อมูลก่อนที่จะดำเนินการเขียนเกิดขึ้น ตรงกันข้าม newData ตัวแปรมีข้อมูลใหม่ที่จะอยู่ถ้าการดำเนินการเขียนจะประสบความสำเร็จ newData หมายถึงผลที่ผสานข้อมูลใหม่ถูกเขียนและข้อมูลที่มีอยู่

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

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

การอ้างอิงข้อมูลในเส้นทางอื่น

ข้อมูลใดๆ สามารถใช้เป็นเกณฑ์สำหรับกฎได้ ใช้กำหนดไว้ล่วงหน้าตัวแปร root , data และ newData เราสามารถเข้าถึงเส้นทางใด ๆ ที่เป็นมันจะมีอยู่ก่อนหรือหลังเหตุการณ์การเขียน

ลองพิจารณาตัวอย่างนี้ซึ่งจะช่วยให้การดำเนินการเขียนตราบใดที่ค่าของ /allow_writes/ โหนดเป็น true ที่โหนดแม่ไม่ได้ readOnly ชุดธงและมีเด็กชื่อ foo ในข้อมูลที่เขียนขึ้นใหม่:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

กำลังตรวจสอบข้อมูล

การบังคับใช้โครงสร้างข้อมูลและการตรวจสอบรูปแบบและเนื้อหาของข้อมูลที่ควรจะทำโดยใช้ .validate กฎซึ่งจะดำเนินการเฉพาะหลังจากที่ .write กฎประสบความสำเร็จให้สิทธิการเข้าถึง ด้านล่างเป็นตัวอย่าง .validate นิยามกฎซึ่งเพียง แต่ช่วยให้วันที่ในรูปแบบ YYYY-MM-DD ระหว่างปี 1900-2099 ซึ่งมีการตรวจสอบโดยใช้การแสดงออกปกติ

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

.validate กฎเป็นชนิดเดียวของกฎการรักษาความปลอดภัยซึ่งไม่ได้มีน้ำตก ถ้ากฎการตรวจสอบใด ๆ ล้มเหลวในเร็กคอร์ดย่อย การดำเนินการเขียนทั้งหมดจะถูกปฏิเสธ นอกจากนี้คำจำกัดความของการตรวจสอบจะถูกละเว้นเมื่อข้อมูลที่ถูกลบ (นั่นคือเมื่อค่าใหม่ถูกเขียนเป็น null )

สิ่งเหล่านี้อาจดูเหมือนเป็นเรื่องเล็กน้อย แต่จริงๆ แล้วเป็นฟีเจอร์ที่สำคัญสำหรับการเขียนกฎความปลอดภัยของฐานข้อมูลแบบเรียลไทม์ของ Firebase Realtime พิจารณากฎต่อไปนี้:

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

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

var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);

FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];

var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

ตอนนี้ให้ดูที่โครงสร้างเดียวกัน แต่ใช้ .write กฎแทน .validate :

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

ในตัวแปรนี้ การดำเนินการใดๆ ต่อไปนี้จะสำเร็จ:

var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);

Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];

var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)

Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);

# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

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

กฎตามแบบสอบถาม

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

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

หลังจากการหารือเกี่ยวกับเงื่อนไขนี้ คุณมีความเข้าใจกฎเกณฑ์ที่ซับซ้อนมากขึ้นและพร้อมที่จะ:

เรียนรู้วิธีจัดการกับกรณีการใช้งานหลัก และเรียนรู้เวิร์กโฟลว์สำหรับการพัฒนา ทดสอบ และปรับใช้กฎ:

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

เรียนรู้คุณสมบัติกฎที่เจาะจงสำหรับฐานข้อมูลเรียลไทม์:

• เรียนรู้วิธีการ ดัชนีฐานข้อมูลเรียลไทม์ของคุณ
• ตรวจสอบ API REST สำหรับการปรับใช้กฎ