เรียนรู้ไวยากรณ์หลักของภาษาของกฎการรักษาความปลอดภัยของ Firebase สำหรับ Cloud Storage

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

คู่มือนี้จะอธิบายไวยากรณ์และโครงสร้างพื้นฐานของกฎการรักษาความปลอดภัยของ Cloud Storage เพื่อ สร้างชุดกฎที่สมบูรณ์

การประกาศบริการและฐานข้อมูล

กฎการรักษาความปลอดภัยของ Firebase สำหรับ Cloud Storage จะเริ่มต้นด้วยการประกาศต่อไปนี้เสมอ

service firebase.storage {
    // ...
}

การประกาศ service firebase.storage จะกำหนดกฎไว้ที่ Cloud Storage เพื่อการป้องกันความขัดแย้งระหว่างกฎการรักษาความปลอดภัยของ Cloud Storage และ สำหรับผลิตภัณฑ์อื่นๆ เช่น Cloud Firestore

กฎการอ่าน/เขียนพื้นฐาน

กฎพื้นฐานประกอบด้วยคำสั่ง match ที่ระบุ Cloud Storage ที่เก็บข้อมูล คำสั่งจับคู่ที่ระบุชื่อไฟล์ และนิพจน์ allow ให้รายละเอียดเมื่ออ่านข้อมูลที่ระบุ allow นิพจน์ ระบุวิธีการเข้าถึง (เช่น อ่าน เขียน) และเงื่อนไข ภายใต้ที่อนุญาตหรือปฏิเสธการเข้าถึง

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

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

ข้อความที่ตรงกันทั้งหมดจะชี้ไปที่ไฟล์ ข้อความจับคู่สามารถชี้ไปยัง เช่นเดียวกับ match /images/profilePhoto.png

จับคู่ไวลด์การ์ด

นอกจากการชี้ไปยังไฟล์เดียวแล้ว กฎยังใช้ไวลด์การ์ดได้อีกด้วย เพื่อชี้ไปยังไฟล์ที่มีคำนำหน้าสตริงที่กำหนดอยู่ในชื่อ รวมถึงเครื่องหมายทับ เช่น match /images/{imageId}

ในตัวอย่างด้านบน คำสั่งจับคู่จะใช้ไวยากรณ์ไวลด์การ์ด {imageId} ซึ่งหมายความว่ากฎนี้จะมีผลกับไฟล์ที่มี /images/ อยู่ขึ้นต้นชื่อ เช่น /images/profilePhoto.png หรือ /images/croppedProfilePhoto.png เมื่อ ระบบประเมินนิพจน์ allow ในคำสั่งการจับคู่ ตัวแปร imageId จะเปลี่ยนเป็นชื่อไฟล์ของรูปภาพ เช่น profilePhoto.png หรือ croppedProfilePhoto.png

อ้างอิงตัวแปรไวลด์การ์ดจากภายใน match เพื่อระบุไฟล์ได้ ชื่อหรือเส้นทางการให้สิทธิ์:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

ข้อมูลตามลําดับชั้น

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

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

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

เมื่อซ้อนคำสั่ง match เส้นทางของคำสั่ง match ด้านในคือ จะต่อท้ายเส้นทางของคำสั่ง match ด้านนอกเสมอ ดังต่อไปนี้ ชุดกฎสองชุดจึงมีความสำคัญเท่ากัน:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

ไวลด์การ์ดการจับคู่ที่เกิดซ้ำ

นอกจากไวลด์การ์ดที่ตรงกันและแสดงผลสตริงที่ส่วนท้ายของชื่อไฟล์แล้ว สามารถประกาศไวลด์การ์ดของกลุ่มหลายกลุ่มสำหรับการจับคู่ที่ซับซ้อนขึ้นได้โดย การเพิ่ม =** ในชื่อไวลด์การ์ด เช่น {path=**}:

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

หากมีกฎหลายข้อตรงกับไฟล์ ผลลัพธ์จะเป็น OR ของผลลัพธ์ทั้งหมด และการประเมินกฎ กล่าวคือ หากกฎใดตรงกับไฟล์ประเมินผลเป็น true ผลลัพธ์คือ true

ในกฎข้างต้น ไฟล์ "images/profilePhoto.png" สามารถอ่านได้ในกรณีต่อไปนี้ condition หรือ other_condition ประเมินผลเป็น "จริง" ขณะที่ไฟล์ "images/users/user:12345/profilePhoto.png" จะขึ้นอยู่กับผลลัพธ์ของ other_condition.

กฎการรักษาความปลอดภัยของ Cloud Storage จะไม่ต่อเนื่อง และจะมีการประเมินกฎเฉพาะเมื่อ เส้นทางคำขอตรงกับเส้นทางที่มีกฎที่ระบุ

เวอร์ชัน 1

กฎการรักษาความปลอดภัยของ Firebase จะใช้เวอร์ชัน 1 โดยค่าเริ่มต้น ในเวอร์ชัน 1 ใช้ไวลด์การ์ดซ้ำ ตรงกับองค์ประกอบชื่อไฟล์อย่างน้อย 1 รายการ ไม่ใช่ 0 หรือมีองค์ประกอบมากกว่า 1 รายการ ดังนั้น match /images/{filenamePrefixWildcard}/{imageFilename=**} ตรงกับชื่อไฟล์ เช่น /images/profilePics/profile.png แต่ไม่ใช่ /images/badge.png ใช้ /images/{imagePrefixorFilename=**} แทน

ไวลด์การ์ดที่เกิดซ้ำต้องอยู่ท้ายคำสั่งการจับคู่

เราขอแนะนำให้ใช้เวอร์ชัน 2 หากต้องการฟีเจอร์ที่มีประสิทธิภาพมากขึ้น

เวอร์ชัน 2

ในกฎการรักษาความปลอดภัยของ Firebase เวอร์ชัน 2 ไวลด์การ์ดที่เกิดซ้ำจะจับคู่กับเส้นทาง 0 รายการขึ้นไป รายการ ดังนั้น การแข่งขัน /images/{filenamePrefixWildcard}/{imageFilename=**} รายการ ชื่อไฟล์ /images/profilePics/profile.png และ /images/badge.png

คุณต้องเลือกใช้เวอร์ชัน 2 โดยเพิ่ม rules_version = '2'; ที่ด้านบนสุดของ กฎความปลอดภัยของคุณ:

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

คุณสามารถมีไวลด์การ์ดซ้ำได้สูงสุด 1 รายการต่อคำสั่งจับคู่ แต่ เวอร์ชัน 2 คุณสามารถวางไวลด์การ์ดนี้ไว้ที่ใดก็ได้ในคำสั่งการจับคู่ สำหรับ ตัวอย่าง:

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

การดำเนินการแบบละเอียด

ในบางสถานการณ์ การจำแนก read และ write เป็นรายละเอียดเพิ่มเติมอาจมีประโยชน์ การดำเนินงานแบบละเอียด เช่น แอปของคุณอาจต้องการบังคับใช้ เงื่อนไขในการสร้างไฟล์มากกว่าการลบไฟล์

แบ่งการดำเนินการ read ออกเป็น get และ list ได้

มีกฎ write รายการได้ ออกเป็น create, update และ delete:

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

ข้อความการจับคู่ที่ทับซ้อนกัน

ชื่อไฟล์อาจตรงกับคำสั่ง match มากกว่า 1 รายการ ใน ในกรณีที่นิพจน์ allow หลายรายการตรงกับคำขอ ระบบจะอนุญาตการเข้าถึง หากเงื่อนไขใดๆ เป็น true:

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

ในตัวอย่างข้างต้น การอ่านและเขียนทั้งหมดไปยังไฟล์ที่มีชื่อขึ้นต้นด้วย อนุญาตให้ใช้/images/ได้ เนื่องจากกฎข้อที่ 2 จะเป็น true เสมอ แม้ว่า กฎแรกคือ false

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

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

ตัวอย่างเช่น ให้ใช้กฎความปลอดภัยต่อไปนี้

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

ปฏิเสธ: กฎนี้ปฏิเสธรายการต่อไปนี้ เนื่องจากชุดผลลัพธ์สามารถรวมไฟล์ที่ contentType อยู่ ไม่ใช่ image/png:

เว็บ
filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

กฎในกฎความปลอดภัยของ Cloud Storage จะประเมินการค้นหาแต่ละรายการตามศักยภาพ ไม่สำเร็จและดำเนินการตามคำขอไม่สำเร็จ หากสามารถแสดงผลไฟล์ที่ไคลเอ็นต์ดำเนินการ ไม่มีสิทธิ์อ่าน คำขอเข้าถึงต้องเป็นไปตามข้อจำกัดที่กำหนดโดย กฎของคุณได้

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

คุณจะทำความเข้าใจกฎการรักษาความปลอดภัยของ Firebase สำหรับ Cloud Storage ได้ลึกซึ้งยิ่งขึ้น ดังนี้

คุณสำรวจกรณีการใช้งานกฎการรักษาความปลอดภัยของ Firebase สำหรับ Cloud Storage โดยเฉพาะได้ดังนี้