Firebase Security Rules cho Cloud Storage cho phép bạn kiểm soát quyền truy cập vào các đối tượng được lưu trữ trong các bộ chứa Cloud Storage. Cú pháp quy tắc linh hoạt cho phép bạn tạo quy tắc để kiểm soát mọi thao tác, từ tất cả các thao tác ghi vào bộ chứa Cloud Storage cho đến các thao tác trên một tệp cụ thể.
Hướng dẫn này mô tả cú pháp và cấu trúc cơ bản của Cloud Storage Security Rules để tạo các quy tắc hoàn chỉnh.
Khai báo dịch vụ và cơ sở dữ liệu
Firebase Security Rules cho Cloud Storage luôn bắt đầu bằng nội dung khai báo sau:
service firebase.storage {
// ...
}
Nội dung khai báo service firebase.storage đưa ra phạm vi cho các quy tắc là
Cloud Storage, ngăn chặn xung đột giữa Cloud Storage Security Rules và
các quy tắc cho các sản phẩm khác như Cloud Firestore.
Quy tắc đọc/ghi cơ bản
Quy tắc cơ bản bao gồm câu lệnh match xác định các bộ chứa Cloud Storage, câu lệnh khớp chỉ định tên tệp và biểu thức allow nêu chi tiết thời điểm cho phép đọc dữ liệu đã chỉ định. Biểu thức allow chỉ định các phương thức truy cập (ví dụ: đọc, ghi) liên quan và các điều kiện cho phép hoặc từ chối quyền truy cập.
Trong bộ quy tắc mặc định, câu lệnh match đầu tiên sử dụng biểu thức ký tự đại diện {bucket} để cho biết các quy tắc áp dụng cho tất cả các bộ chứa trong dự án. Chúng ta sẽ thảo luận thêm về ý tưởng so khớp ký tự đại diện trong phần tiếp theo.
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>;
}
}
}
Tất cả câu lệnh so khớp đều trỏ đến tệp. Câu lệnh so khớp có thể trỏ đến một tệp cụ thể, như trong match /images/profilePhoto.png.
Khớp với ký tự đại diện
Ngoài việc trỏ đến một tệp duy nhất, Rules có thể sử dụng ký tự đại diện để trỏ đến bất kỳ tệp nào có tiền tố chuỗi nhất định trong tên, bao gồm cả dấu gạch chéo, như trong match /images/{imageId}.
Trong ví dụ trên, câu lệnh so khớp sử dụng cú pháp ký tự đại diện {imageId}.
Điều này có nghĩa là quy tắc áp dụng cho mọi tệp có /images/ ở đầu tên, chẳng hạn như /images/profilePhoto.png hoặc /images/croppedProfilePhoto.png. Khi các biểu thức allow trong câu lệnh so khớp được đánh giá, biến imageId sẽ phân giải thành tên tệp hình ảnh, chẳng hạn như profilePhoto.png hoặc croppedProfilePhoto.png.
Bạn có thể tham chiếu biến đại diện từ bên trong match để cung cấp tên tệp hoặc quyền truy cập đường dẫn:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
Dữ liệu phân cấp
Như đã đề cập trước đó, không có cấu trúc phân cấp nào bên trong bộ chứa Cloud Storage. Tuy nhiên, bằng cách sử dụng quy ước đặt tên tệp, thường là một quy ước có dấu gạch chéo trong tên tệp, chúng ta có thể mô phỏng một cấu trúc trông giống như một loạt thư mục và thư mục con lồng nhau. Điều quan trọng là bạn phải hiểu cách Firebase Security Rules tương tác với các tên tệp này.
Hãy xem xét trường hợp một tập hợp tệp có tên đều bắt đầu bằng gốc /images/. Firebase Security Rules chỉ áp dụng tại tên tệp được so khớp, vì vậy, các chế độ kiểm soát truy cập được xác định trên thân /images/ sẽ không áp dụng cho thân /mp3s/.
Thay vào đó, hãy viết các quy tắc rõ ràng khớp với nhiều mẫu tên tệp:
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>;
}
}
}
Khi lồng các câu lệnh match, đường dẫn của câu lệnh match bên trong luôn được thêm vào đường dẫn của câu lệnh match bên ngoài. Do đó, hai bộ quy tắc sau đây tương đương với nhau:
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>;
}
}
}
Ký tự đại diện so khớp đệ quy
Ngoài các ký tự đại diện khớp và trả về chuỗi ở cuối tên tệp, bạn có thể khai báo ký tự đại diện nhiều phân đoạn để so khớp phức tạp hơn bằng cách thêm =** vào tên ký tự đại diện, chẳng hạn như {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>;
}
}
Nếu nhiều quy tắc khớp với một tệp, kết quả sẽ là OR của kết quả tất cả các quy tắc đánh giá. Tức là nếu bất kỳ quy tắc nào mà tệp khớp với đều đánh giá là true, thì kết quả sẽ là true.
Trong các quy tắc ở trên, tệp "images/profilePhoto.png" có thể được đọc nếu condition hoặc other_condition đánh giá là đúng, trong khi tệp "images/users/user:12345/profilePhoto.png" chỉ tuân theo kết quả của other_condition.
Cloud Storage Security Rules không tạo hiệu ứng lũy thừa và các quy tắc chỉ được đánh giá khi đường dẫn yêu cầu khớp với đường dẫn có quy tắc được chỉ định.
Phiên bản 1
Theo mặc định, Firebase Security Rules sử dụng phiên bản 1. Trong phiên bản 1, ký tự đại diện đệ quy khớp với một hoặc nhiều phần tử tên tệp, chứ không phải không có hoặc nhiều phần tử. Do đó, match /images/{filenamePrefixWildcard}/{imageFilename=**} khớp với tên tệp như /images/profilePics/profile.png, nhưng không khớp với /images/badge.png. Thay vào đó, hãy sử dụng /images/{imagePrefixorFilename=**}.
Ký tự đại diện đệ quy phải nằm ở cuối câu lệnh so khớp.
Bạn nên sử dụng phiên bản 2 để tận hưởng các tính năng mạnh mẽ hơn.
Phiên bản 2
Trong phiên bản 2 của Firebase Security Rules, ký tự đại diện đệ quy khớp với 0 hoặc nhiều mục đường dẫn. Do đó, /images/{filenamePrefixWildcard}/{imageFilename=**} khớp với tên tệp /images/profilePics/profile.png và /images/badge.png.
Bạn phải chọn sử dụng phiên bản 2 bằng cách thêm rules_version = '2'; vào đầu quy tắc bảo mật:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
Bạn có thể có tối đa một ký tự đại diện đệ quy cho mỗi câu lệnh so khớp, nhưng trong phiên bản 2, bạn có thể đặt ký tự đại diện này ở vị trí bất kỳ trong câu lệnh so khớp. Ví dụ:
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>;
}
}
}
Thao tác chi tiết
Trong một số trường hợp, bạn nên chia nhỏ read và write thành các thao tác chi tiết hơn. Ví dụ: ứng dụng của bạn có thể muốn thực thi các điều kiện khác nhau khi tạo tệp so với khi xoá tệp.
Bạn có thể chia một toán tử read thành get và list.
Bạn có thể chia một quy tắc write thành create, update và 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>;
}
}
}
}
Câu lệnh khớp trùng lặp
Tên tệp có thể khớp với nhiều câu lệnh match. Trong trường hợp nhiều biểu thức allow khớp với một yêu cầu, quyền truy cập sẽ được cho phép nếu bất kỳ điều kiện nào là 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;
}
}
}
Trong ví dụ trên, tất cả các hoạt động đọc và ghi vào các tệp có tên bắt đầu bằng /images/ đều được cho phép vì quy tắc thứ hai luôn là true, ngay cả khi quy tắc đầu tiên là false.
Quy tắc không phải là bộ lọc
Sau khi bạn bảo mật dữ liệu và bắt đầu thực hiện các thao tác trên tệp, hãy lưu ý rằng quy tắc bảo mật không phải là bộ lọc. Bạn không thể thực hiện các thao tác trên một tập hợp tệp khớp với mẫu tên tệp và mong đợi Cloud Storage chỉ truy cập vào các tệp mà ứng dụng hiện tại có quyền truy cập.
Ví dụ: hãy xem quy tắc bảo mật sau:
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';
}
}
}
Bị từ chối: Quy tắc này từ chối yêu cầu sau đây vì tập hợp kết quả có thể bao gồm các tệp mà contentType không phải là image/png:
Web
filesRef = storage.ref().child("aFilenamePrefix");
filesRef.listAll()
.then(function(result) {
console.log("Success: ", result.items);
})
});
Các quy tắc trong Cloud Storage Security Rules đánh giá từng truy vấn dựa trên kết quả tiềm năng và từ chối yêu cầu nếu truy vấn có thể trả về một tệp mà ứng dụng không có quyền đọc. Yêu cầu truy cập phải tuân theo các quy tắc ràng buộc do bạn đặt ra.
Các bước tiếp theo
Bạn có thể hiểu rõ hơn về Firebase Security Rules cho Cloud Storage:
Tìm hiểu khái niệm chính tiếp theo của ngôn ngữ Quy tắc, đó là điều kiện động, cho phép Quy tắc của bạn kiểm tra quyền uỷ quyền của người dùng, so sánh dữ liệu hiện có và dữ liệu đến, xác thực dữ liệu đến, v.v.
Xem xét các trường hợp sử dụng bảo mật thông thường và các định nghĩa Firebase Security Rules giải quyết các trường hợp đó.
Bạn có thể khám phá các trường hợp sử dụng Firebase Security Rules dành riêng cho Cloud Storage: