Reguły bezpieczeństwa Firebase dla Cloud Storage pozwalają kontrolować dostęp do obiektów przechowywanych w zasobnikach Cloud Storage. Elastyczna składnia reguł umożliwia tworzenie reguł kontrolujących dowolne operacje, od wszystkich zapisów w zasobniku Cloud Storage po operacje na określonym pliku.
W tym przewodniku opisano podstawową składnię i strukturę reguł bezpieczeństwa Cloud Storage, aby utworzyć kompletne zestawy reguł.
Deklaracja usługi i bazy danych
Reguły bezpieczeństwa Firebase dla Cloud Storage zawsze zaczynają się od następującej deklaracji:
service firebase.storage {
// ...
}
Deklaracja service firebase.storage
obejmuje zakres reguł do Cloud Storage, zapobiegając konfliktom między Regułami bezpieczeństwa Cloud Storage a regułami dla innych produktów, takich jak Cloud Firestore.
Podstawowe zasady odczytu/zapisu
Podstawowe reguły obejmują instrukcję match
identyfikującą zasobniki Cloud Storage, instrukcję dopasowania określającą nazwę pliku oraz wyrażenie allow
określające, kiedy odczyt określonych danych jest dozwolony. wyrażenia allow
określają stosowane metody dostępu (np. odczyt, zapis) oraz warunki , w których dostęp jest dozwolony lub zabroniony.
W domyślnym zestawie reguł pierwsza instrukcja match
używa symbolu wieloznacznego {bucket}
, aby wskazać, że reguły mają zastosowanie do wszystkich zasobników w projekcie. Omówimy ideę dopasowań wieloznacznych więcej w następnej sekcji.
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>;
}
}
}
Wszystkie instrukcje dopasowania wskazują na pliki. Instrukcja match może wskazywać na konkretny plik, jak w match /images/profilePhoto.png
.
Dopasuj symbole wieloznaczne
Oprócz wskazywania pojedynczego pliku, Reguły mogą używać symboli wieloznacznych do wskazywania dowolnego pliku z danym prefiksem w nazwie, w tym ukośnikami, jak w match /images/{imageId}
.
W powyższym przykładzie instrukcja dopasowania używa symboli wieloznacznych {imageId}
. Oznacza to, że reguła dotyczy każdego pliku, którego nazwa zaczyna się od /images/
, na przykład /images/profilePhoto.png
lub /images/croppedProfilePhoto.png
. Po ocenie wyrażeń allow
w instrukcji dopasowania zmienna imageId
zostanie rozpoznana jako nazwa pliku obrazu, na przykład profilePhoto.png
lub croppedProfilePhoto.png
.
Można odwoływać się do zmiennej wieloznacznej z poziomu match
, aby podać nazwę pliku lub autoryzację ścieżki:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
Dane hierarchiczne
Jak powiedzieliśmy wcześniej, wewnątrz zasobnika Cloud Storage nie ma hierarchicznej struktury. Ale stosując konwencję nazewnictwa plików, często taką, która zawiera ukośniki w nazwach plików, możemy naśladować strukturę, która wygląda jak zagnieżdżona seria katalogów i podkatalogów. Ważne jest, aby zrozumieć, w jaki sposób Reguły bezpieczeństwa Firebase wchodzą w interakcję z tymi nazwami plików.
Rozważmy sytuację zbioru plików, których nazwy zaczynają się od rdzenia /images/
. Reguły bezpieczeństwa Firebase mają zastosowanie tylko do dopasowanej nazwy pliku, więc kontrola dostępu zdefiniowana w /images/
trzpieniu nie ma zastosowania do trzpienia /mp3s/
. Zamiast tego napisz wyraźne reguły pasujące do różnych wzorców nazw plików:
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>;
}
}
}
Podczas zagnieżdżania instrukcji match
ścieżka wewnętrznej instrukcji match
jest zawsze dołączana do ścieżki zewnętrznej instrukcji match
. Poniższe dwa zestawy reguł są zatem równoważne:
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>;
}
}
}
Wieloznaczne dopasowania rekurencyjne
Oprócz symboli wieloznacznych, które dopasowują i zwracają ciąg znaków na końcu nazwy pliku, można zadeklarować symbol wieloznaczny z wieloma segmentami w celu bardziej złożonego dopasowania, dodając =**
do nazwy symbolu wieloznacznego, na przykład {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>;
}
}
Jeśli do pliku pasuje wiele reguł, wynikiem jest OR
wyniku wszystkich ocen reguł. Oznacza to, że jeśli jakakolwiek reguła, do której pasuje plik, ma wartość true
, wynikiem jest true
.
W powyższych regułach plik „images/profilePhoto.png” można odczytać, jeśli condition
lub other_condition
ma wartość true, podczas gdy plik „images/users/user:12345/profilePhoto.png” podlega tylko wynikowi other_condition
.
Reguły bezpieczeństwa Cloud Storage nie są kaskadowane, a reguły są oceniane tylko wtedy, gdy ścieżka żądania odpowiada ścieżce z określonymi regułami.
Wersja 1
Reguły bezpieczeństwa Firebase domyślnie używają wersji 1. W wersji 1 rekurencyjne symbole wieloznaczne dopasowują jeden lub więcej elementów nazwy pliku, a nie zero lub więcej elementów. Zatem match /images/{filenamePrefixWildcard}/{imageFilename=**}
pasuje do nazwy pliku takiej jak /images/profilePics/profile.png, ale nie do /images/badge.png. Zamiast tego użyj /images/{imagePrefixorFilename=**}
.
Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.
Zalecamy korzystanie z wersji 2 ze względu na jej bardziej zaawansowane funkcje.
Wersja 2
W wersji 2 Reguł bezpieczeństwa Firebase rekurencyjne symbole wieloznaczne pasują do zera lub większej liczby elementów ścieżki. Zatem /images/{filenamePrefixWildcard}/{imageFilename=**}
dopasowuje nazwy plików /images/profilePics/profile.png i /images/badge.png.
Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2';
u góry reguł bezpieczeństwa:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
Możesz mieć co najwyżej jeden rekurencyjny symbol wieloznaczny na instrukcję dopasowania, ale w wersji 2 możesz umieścić ten symbol wieloznaczny w dowolnym miejscu instrukcji dopasowania. Na przykład:
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>;
}
}
}
Operacje szczegółowe
W niektórych sytuacjach warto podzielić read
i write
na bardziej szczegółowe operacje. Na przykład Twoja aplikacja może chcieć wymusić inne warunki przy tworzeniu plików niż przy ich usuwaniu.
Operację read
można podzielić na get
i list
.
Regułę write
można podzielić na create
, update
i 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>; } } } }
Nakładające się instrukcje dopasowania
Nazwa pliku może pasować do więcej niż jednej instrukcji match
. W przypadku, gdy wiele wyrażeń allow
pasuje do żądania, dostęp jest dozwolony, jeśli którykolwiek z warunków jest 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;
}
}
}
W powyższym przykładzie wszystkie odczyty i zapisy do plików, których nazwa zaczyna się od /images/
są dozwolone, ponieważ druga reguła jest zawsze true
, nawet jeśli pierwsza reguła jest false
.
Reguły nie są filtrami
Po zabezpieczeniu danych i rozpoczęciu operacji na plikach należy pamiętać, że reguły bezpieczeństwa nie są filtrami. Nie możesz wykonywać operacji na zbiorze plików pasujących do wzorca nazwy pliku i oczekiwać, że Cloud Storage uzyska dostęp tylko do plików, do których bieżący klient ma uprawnienia dostępu.
Weźmy na przykład następującą regułę bezpieczeństwa:
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';
}
}
}
Odmowa : Ta reguła odrzuca następujące żądanie, ponieważ zestaw wyników może zawierać pliki, w których contentType
nie jest image/png
:
Sieć
filesRef = storage.ref().child("aFilenamePrefix"); filesRef.listAll() .then(function(result) { console.log("Success: ", result.items); }) });
Reguły w Cloud Storage Security Rules oceniają każde zapytanie pod kątem jego potencjalnego wyniku i odrzucają żądanie, jeśli mogłoby ono zwrócić plik, do którego klient nie ma uprawnień do odczytu. Żądania dostępu muszą być zgodne z ograniczeniami określonymi przez Twoje reguły.
Następne kroki
Możesz pogłębić swoją wiedzę na temat Reguł bezpieczeństwa Firebase dla Cloud Storage:
Poznaj kolejną ważną koncepcję języka Reguł, dynamicznych warunków , które pozwalają Regułom sprawdzać autoryzację użytkownika, porównywać istniejące i przychodzące dane, weryfikować poprawność danych przychodzących i nie tylko.
Przejrzyj typowe przypadki użycia zabezpieczeń i odnoszące się do nich definicje Reguł bezpieczeństwa Firebase .
Możesz zapoznać się z przypadkami użycia Reguł bezpieczeństwa Firebase specyficznymi dla Cloud Storage: