Firebase Security Rules w domenie Cloud Storage pozwala kontrolować dostęp do przechowywanych obiektów w Cloud Storage zasobnikach. Elastyczna składnia reguł umożliwia do kontrolowania dowolnej operacji, od wszystkich zapisów do Cloud Storage do operacji na konkretnym pliku.
W tym przewodniku opisano podstawową składnię i strukturę komponentów Cloud Storage Security Rules w aby utworzyć kompletne zestawy reguł.
Deklaracja dotycząca usługi i bazy danych
Firebase Security Rules w przypadku elementu Cloud Storage zawsze zaczyna się od tej deklaracji:
service firebase.storage {
// ...
}
Deklaracja service firebase.storage
ogranicza reguły do zakresu
Cloud Storage, co zapobiega konfliktom między Cloud Storage Security Rules a
reguły dla innych usług, np. Cloud Firestore.
Podstawowe reguły odczytu/zapisu
Reguły podstawowe składają się z instrukcji match
identyfikującej Cloud Storage
zasobnika, instrukcję dopasowania określającą nazwę pliku oraz wyrażenie allow
przy odczytywaniu
określonych danych. allow
wyrażenia
określ używane metody dostępu (np.odczyt, zapis) i warunki.
w ramach których jest dozwolony lub zabroniony dostęp.
W domyślnym zestawie reguł pierwsza instrukcja match
używa symbolu wieloznacznego {bucket}
wskazuje, że reguły mają zastosowanie do wszystkich zasobników w projekcie. Na
Omówimy koncepcję dopasowań z symbolami wieloznacznymi 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ą pliki. Wyrażenie dopasowania może wskazywać określony element,
taki jak match /images/profilePhoto.png
.
Dopasuj symbole wieloznaczne
Oprócz wskazania pojedynczego pliku Rules może używać symboli wieloznacznych
wskazuje dowolny plik, który w nazwie ma określony prefiks ciągu znaków, w tym ukośniki,
na przykład match /images/{imageId}
.
W przykładzie powyżej instrukcja dopasowania używa składni z symbolem wieloznacznym {imageId}
.
Oznacza to, że reguła będzie stosowana do każdego pliku, którego nazwa zaczyna się od /images/
,
na przykład /images/profilePhoto.png
lub /images/croppedProfilePhoto.png
. Gdy
Wyrażenia (allow
) w wyrażeniu dopasowania są sprawdzane, zmienna imageId
będzie pobierać nazwę pliku obrazu, taką jak profilePhoto.png
lub
croppedProfilePhoto.png
W match
można się odwoływać do zmiennej z symbolem wieloznacznym, aby dostarczyć plik
autoryzacja nazwy lub ścieżki:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
Dane hierarchiczne
Jak wspomnieliśmy wcześniej, wewnątrz nie ma struktury hierarchicznej Zasobnik Cloud Storage. Konwencja nazewnictwa plików często polega na zawierających ukośniki w nazwach plików, możemy naśladować strukturę, zagnieżdżona seria katalogów i podkatalogów. Warto wiedzieć, jak Firebase Security Rules wchodzi w interakcję z tymi nazwami plików.
Weźmy pod uwagę sytuację z zestawem plików, których nazwy zaczynają się od
Łodyga /images/
. Firebase Security Rules ma zastosowanie tylko do pasującej nazwy pliku, więc dostęp
elementy sterujące zdefiniowane w rdzeniu /images/
nie mają zastosowania do źródła /mp3s/
.
Zamiast tego utwórz jawne reguły, które pasują 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>;
}
}
}
Gdy zagnieżdżasz instrukcje match
, ścieżka wewnętrznej instrukcji match
ma postać
zawsze dołączana do ścieżki zewnętrznej instrukcji match
. Poniżej
dwa zestawy reguł są więc 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>;
}
}
}
Symbole wieloznaczne dopasowania rekurencyjnego
Oprócz symboli wieloznacznych, które pasują i zwracają ciągi znaków na końcu nazwy pliku,
W celu uzyskania bardziej złożonego dopasowania można zadeklarować symbol wieloznaczny dla wielu segmentów przez
dodanie =**
do nazwy symbolu wieloznacznego, np. {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ł, wynik to OR
wszystkich reguł
weryfikacji reguł. Oznacza to, że jeśli dowolna reguła pasująca do pliku zwraca wartość true
,
wynik to true
.
W regułach powyżej plik „images/profilePhoto.png” można odczytać, jeśli:
condition
lub other_condition
zwracają wartość prawda, a plik
„images/users/user:12345/profilePhoto.png” zależy jedynie od wyniku
other_condition
Cloud Storage Security Rules nie są kaskadowe, a reguły są oceniane tylko wtedy, gdy Ścieżka żądania pasuje do ścieżki z określonymi regułami.
Wersja 1
Firebase Security Rules używają domyślnie wersji 1. w wersji 1 rekurencyjne symbole wieloznaczne;
dopasowuj co najmniej 1 element nazwy pliku, a nie zero lub więcej elementów. W związku z tym:
match /images/{filenamePrefixWildcard}/{imageFilename=**}
pasuje do nazwy pliku
np. /images/profilePics/profile.png, ale nie /images/badge.png. Używaj
/images/{imagePrefixorFilename=**}
.
Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.
Ze względu na bardziej zaawansowane funkcje zalecamy używanie wersji 2.
Wersja 2
W wersji 2 systemu Firebase Security Rules rekurencyjne symbole wieloznaczne pasują do 0 lub większej liczby ścieżek
elementy(ów). Tyle wyników pasuje do: /images/{filenamePrefixWildcard}/{imageFilename=**}
nazwy plików /images/profilePics/profile.png i /images/badge.png.
Musisz zaakceptować wersję 2, dodając rules_version = '2';
u góry
Twoje reguły zabezpieczeń:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
Możesz użyć tylko jednego rekurencyjnego symbolu wieloznacznego na wyrażenie dopasowania, ale w wersji 2, możesz umieścić ten symbol wieloznaczny w dowolnym miejscu w instrukcji dopasowania. 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
do bardziej szczegółowych działań. Aplikacja może na przykład wymuszać w aplikacji różne
warunki tworzenia pliku niż przy jego usunięciu.
Operacja read
można podzielić na get
i list
.
Reguła write
może być
podzielone 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
Może się zdarzyć, że nazwa pliku będzie pasowała do więcej niż jednej instrukcji match
. W
jeśli do żądania pasuje wiele wyrażeń allow
, 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 w plikach, których nazwa zaczyna się od
/images/
są dozwolone, ponieważ druga reguła jest zawsze true
, nawet jeśli
pierwsza reguła to false
.
Reguły nie są filtrami
Gdy zabezpieczysz dane i zaczniesz wykonywać operacje na plikach, pamiętaj, że reguły zabezpieczeń nie są filtrami. Nie można wykonać operacji na zbiorze pliki pasujące do wzorca nazwy pliku i oczekują, że program Cloud Storage będzie miał dostęp tylko które pliki są dostępne dla bieżącego klienta.
Na przykład użyj tej reguły zabezpieczeń:
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';
}
}
}
Odrzucono: ta reguła odrzuca następujące wyniki:
, ponieważ zbiór wyników może zawierać pliki, w których contentType
jest
nie 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 potencjału i nie powiedzie się, jeśli może zwrócić plik wykonany przez klienta nie mają uprawnień do odczytu. Prośby o dostęp muszą być zgodne z ograniczeniami ustawionymi przez swoje reguły.
Dalsze kroki
Możesz poszerzyć swoją wiedzę na temat Firebase Security Rules w Cloud Storage:
Poznaj kolejną główną pojęcie języka reguł – dynamiczny. warunków, które pozwalają regułom sprawdzać autoryzację użytkownika porównywać istniejące i przychodzące dane, weryfikować dane przychodzące i wykonywać inne działania.
Zapoznaj się z typowymi przypadkami użycia zabezpieczeń oraz Firebase Security Rules definicji dotyczących tych kwestii.
Możesz zapoznać się z Firebase Security Rules przypadkami użycia charakterystycznymi dla Cloud Storage: