Bezpieczeństwo może być jednym z najbardziej złożonych elementów układanki tworzenia aplikacji. W większości aplikacji programiści muszą zbudować i uruchomić serwer, który obsługuje uwierzytelnianie (to, kim jest użytkownik) i autoryzację (co może zrobić użytkownik).
Reguły bezpieczeństwa Firebase usuwają warstwę środkową (serwerową) i umożliwiają określanie uprawnień opartych na ścieżce dla klientów, którzy łączą się bezpośrednio z Twoimi danymi. Skorzystaj z tego przewodnika, aby dowiedzieć się więcej o tym, jak reguły są stosowane do żądań przychodzących.
Wybierz produkt, aby dowiedzieć się więcej o jego zasadach.
Cloud Firestore
Podstawowa struktura
Reguły bezpieczeństwa Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Podczas tworzenia reguł ważne jest zrozumienie następujących kluczowych pojęć:
- Żądanie: metoda lub metody wywołane w instrukcji
allow. To są metody, na których działanie zezwalasz. Standardowe metody to:get,list,create,updateidelete. Wygodne metodyreadiwriteumożliwiają szeroki dostęp do odczytu i zapisu w określonej ścieżce bazy danych lub magazynu. - Ścieżka: Baza danych lub lokalizacja magazynu reprezentowana jako ścieżka URI.
- Reguła: instrukcja
allow, która zawiera warunek zezwalający na żądanie, jeśli ma ono wartość true.
Zasady bezpieczeństwa wersja 2
Od maja 2019 r. dostępna jest wersja 2 reguł bezpieczeństwa Firebase. Wersja 2 reguł zmienia zachowanie rekurencyjnych symboli wieloznacznych {name=**} . Musisz użyć wersji 2, jeśli planujesz używać kwerend dotyczących grup kolekcji . Musisz wyrazić zgodę na wersję 2, ustawiając rules_version = '2'; pierwsza linia w twoich regułach bezpieczeństwa:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
Pasujące ścieżki
Wszystkie instrukcje dopasowania powinny wskazywać dokumenty, a nie kolekcje. Instrukcja match może wskazywać na konkretny dokument, jak w match /cities/SF lub użyć symboli wieloznacznych, aby wskazać dowolny dokument w określonej ścieżce, jak w match /cities/{city} .
W powyższym przykładzie instrukcja dopasowania używa symboli wieloznacznych {city} . Oznacza to, że reguła ma zastosowanie do dowolnego dokumentu w kolekcji cities , takiego jak /cities/SF lub /cities/NYC . Po ocenie wyrażeń allow w instrukcji dopasowania zmienna city zostanie rozpoznana jako nazwa dokumentu miasta, na przykład SF lub NYC .
Pasujące podkolekcje
Dane w Cloud Firestore są zorganizowane w kolekcje dokumentów, a każdy dokument może rozszerzać hierarchię poprzez podkolekcje. Ważne jest, aby zrozumieć, w jaki sposób reguły bezpieczeństwa wchodzą w interakcję z danymi hierarchicznymi.
Rozważmy sytuację, w której każdy dokument w zbiorze cities zawiera podzbiór landmarks . Reguły bezpieczeństwa mają zastosowanie tylko do dopasowanej ścieżki, więc kontrola dostępu zdefiniowana w zbiorze cities nie ma zastosowania do podzbioru landmarks . Zamiast tego napisz wyraźne reguły kontrolujące dostęp do podkolekcji:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
allow read, write: if <condition>;
// Explicitly define rules for the 'landmarks' subcollection
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
Podczas zagnieżdżania instrukcji match ścieżka wewnętrznej instrukcji match jest zawsze względna względem ścieżki zewnętrznej instrukcji match . Następujące zestawy reguł są zatem równoważne:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city}/landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
Rekurencyjne symbole wieloznaczne
Jeśli chcesz, aby reguły miały zastosowanie do dowolnie głębokiej hierarchii, użyj rekurencyjnej składni symboli wieloznacznych, {name=**} :
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{document=**} {
allow read, write: if <condition>;
}
}
}
W przypadku użycia rekurencyjnej składni symboli wieloznacznych zmienna wieloznaczna będzie zawierać cały pasujący segment ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonej podkolekcji. Na przykład reguły wymienione powyżej pasowałyby do dokumentu znajdującego się w /cities/SF/landmarks/coit_tower , a wartość zmiennej document to SF/landmarks/coit_tower .
Należy jednak pamiętać, że zachowanie rekurencyjnych symboli wieloznacznych zależy od wersji reguł.
Wersja 1
Reguły bezpieczeństwa domyślnie używają wersji 1. W wersji 1 rekurencyjne symbole wieloznaczne pasują do jednego lub większej liczby elementów ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**} dopasowuje dokumenty w podkolekcjach, ale nie w kolekcji cities , natomiast match /cities/{document=**} dopasowuje oba dokumenty w kolekcja cities i podkolekcje.
Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.
Wersja 2
W wersji 2 reguł bezpieczeństwa rekurencyjne symbole wieloznaczne pasują do zera lub większej liczby elementów ścieżki. match/cities/{city}/{document=**} dopasowuje dokumenty w dowolnych podkolekcjach, jak również dokumenty w kolekcji cities .
Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2'; u góry reguł bezpieczeństwa:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{city}/{document=**} {
allow read, write: if <condition>;
}
}
}
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 cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the songs collection group
match /{path=**}/songs/{song} {
allow read, write: if <condition>;
}
}
}
W przypadku korzystania z zapytań dotyczących grup kolekcji należy używać wersji 2, patrz zabezpieczanie zapytań dotyczących grup kolekcji .
Nakładające się instrukcje dopasowania
Dokument 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 cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the 'cities' collection.
match /cities/{city} {
allow read, write: if false;
}
// Matches any document in the 'cities' collection or subcollections.
match /cities/{document=**} {
allow read, write: if true;
}
}
}
W powyższym przykładzie wszystkie odczyty i zapisy do kolekcji cities będą dozwolone, ponieważ druga reguła jest zawsze true , mimo że pierwsza reguła jest zawsze false .
Limity reguł bezpieczeństwa
Podczas pracy z regułami bezpieczeństwa należy zwrócić uwagę na następujące ograniczenia:
| Limit | Detale |
|---|---|
Maksymalna liczba exists() , get() i getAfter() na żądanie |
Przekroczenie któregokolwiek z limitów skutkuje błędem odmowy uprawnień. Niektóre wywołania dostępu do dokumentów mogą być buforowane, a wywołania buforowane nie wliczają się do limitów. |
Maksymalna głębokość zagnieżdżonej instrukcji match | 10 |
Maksymalna długość ścieżki, w segmentach ścieżki, dozwolona w zestawie zagnieżdżonych instrukcji match | 100 |
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolona w zestawie zagnieżdżonych instrukcji match | 20 |
| Maksymalna głębokość wywołania funkcji | 20 |
| Maksymalna liczba argumentów funkcji | 7 |
Maksymalna liczba powiązań zmiennych let na funkcję | 10 |
| Maksymalna liczba rekurencyjnych lub cyklicznych wywołań funkcji | 0 (niedozwolone) |
| Maksymalna liczba wyrażeń ocenianych na żądanie | 1000 |
| Maksymalny rozmiar zestawu reguł | Zestawy reguł muszą przestrzegać dwóch ograniczeń rozmiaru:
|
Magazyn w chmurze
Podstawowa struktura
Reguły bezpieczeństwa Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Podczas tworzenia reguł ważne jest zrozumienie następujących kluczowych pojęć:
- Żądanie: metoda lub metody wywołane w instrukcji
allow. To są metody, na których działanie zezwalasz. Standardowe metody to:get,list,create,updateidelete. Wygodne metodyreadiwriteumożliwiają szeroki dostęp do odczytu i zapisu w określonej ścieżce bazy danych lub magazynu. - Ścieżka: Baza danych lub lokalizacja magazynu reprezentowana jako ścieżka URI.
- Reguła: instrukcja
allow, która zawiera warunek zezwalający na żądanie, jeśli ma ono wartość true.
Pasujące ścieżki
Reguły bezpieczeństwa Cloud Storage match ścieżkami plików używanymi do uzyskiwania dostępu do plików w Cloud Storage. Reguły mogą match dokładnym ścieżkom lub ścieżkom wieloznacznym, a także mogą być zagnieżdżane. Jeśli żadna reguła dopasowania nie zezwala na metodę żądania lub warunek ma wartość false , żądanie jest odrzucane.
Dokładne dopasowania
// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
allow write: if <condition>;
}
// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
allow write: if <other_condition>;
}
Zagnieżdżone dopasowania
// Partial match for files that start with "images"
match /images {
// Exact match for "images/profilePhoto.png"
match /profilePhoto.png {
allow write: if <condition>;
}
// Exact match for "images/croppedProfilePhoto.png"
match /croppedProfilePhoto.png {
allow write: if <other_condition>;
}
}
Mecze z dziką kartą
Reguł można również użyć do match wzorca za pomocą symboli wieloznacznych. Symbol wieloznaczny to nazwana zmienna, która reprezentuje albo pojedynczy ciąg, taki jak profilePhoto.png , albo wiele segmentów ścieżki, na przykład images/profilePhoto.png .
Symbol wieloznaczny jest tworzony przez dodanie nawiasów klamrowych wokół nazwy symbolu wieloznacznego, na przykład {string} . Symbol wieloznaczny segmentu można zadeklarować, 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/profilePhoto.png is matched
match /{imageId} {
// This rule only matches a single path segment (*)
// imageId is a string that contains the specific segment matched
allow read: if <condition>;
}
// 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 .
Do zmiennej wieloznacznej można się odwoływać z poziomu match , podając nazwę pliku lub autoryzację ścieżki:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
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.
Poproś o ocenę
Przesyłanie, pobieranie, zmiany metadanych i usuwanie są oceniane na podstawie request wysyłanego do Cloud Storage. Zmienna request zawiera ścieżkę do pliku, w którym żądanie jest wykonywane, czas otrzymania żądania oraz nową wartość resource , jeśli żądanie jest zapisem. Uwzględniono również nagłówki HTTP i stan uwierzytelniania.
Obiekt request zawiera również unikalny identyfikator użytkownika i ładunek uwierzytelniania Firebase w obiekcie request.auth , co zostanie dokładniej wyjaśnione w sekcji Uwierzytelnianie w dokumentacji.
Pełna lista właściwości w obiekcie request jest dostępna poniżej:
| Nieruchomość | Typ | Opis |
|---|---|---|
auth | map<łańcuch, ciąg> | Gdy użytkownik jest zalogowany, podaje uid , unikalny identyfikator użytkownika i token , mapę oświadczeń JWT uwierzytelniania Firebase. W przeciwnym razie będzie to null . |
params | map<łańcuch, ciąg> | Mapa zawierająca parametry zapytania żądania. |
path | ścieżka | path reprezentująca ścieżkę, w której wykonywane jest żądanie. |
resource | map<łańcuch, ciąg> | Nowa wartość zasobu, obecna tylko w żądaniach write . |
time | znak czasu | Sygnatura czasowa reprezentująca czas serwera, w którym żądanie jest oceniane. |
Ocena zasobów
Oceniając reguły, możesz również chcieć ocenić metadane przesyłanego, pobieranego, modyfikowanego lub usuwanego pliku. Pozwala to na tworzenie złożonych i zaawansowanych reguł, które pozwalają np. zezwalać na przesyłanie tylko plików o określonym typie zawartości lub usuwanie tylko plików większych niż określony rozmiar.
Reguły bezpieczeństwa Firebase dla Cloud Storage udostępniają metadane pliku w obiekcie resource , który zawiera pary klucz/wartość metadanych udostępnianych w obiekcie Cloud Storage. Te właściwości można sprawdzać podczas żądań read lub write , aby zapewnić integralność danych.
W przypadku żądań write (takich jak przesyłanie, aktualizacja metadanych i usuwanie) oprócz obiektu resource , który zawiera metadane pliku aktualnie istniejącego w ścieżce żądania, masz również możliwość użycia obiektu request.resource , który zawiera podzbiór metadanych pliku do zapisania, jeśli zapis jest dozwolony. Możesz użyć tych dwóch wartości, aby zapewnić integralność danych lub wymusić ograniczenia aplikacji, takie jak typ lub rozmiar pliku.
Pełna lista właściwości w obiekcie resource jest dostępna poniżej:
| Nieruchomość | Typ | Opis |
|---|---|---|
name | strunowy | Pełna nazwa obiektu |
bucket | strunowy | Nazwa zasobnika, w którym znajduje się ten obiekt. |
generation | int | Generowanie obiektu Google Cloud Storage dla tego obiektu. |
metageneration | int | Metageneracja obiektu Google Cloud Storage tego obiektu. |
size | int | Rozmiar obiektu w bajtach. |
timeCreated | znak czasu | Sygnatura czasowa reprezentująca czas utworzenia obiektu. |
updated | znak czasu | Sygnatura czasowa reprezentująca czas ostatniej aktualizacji obiektu. |
md5Hash | strunowy | Skrót MD5 obiektu. |
crc32c | strunowy | Skrót crc32c obiektu. |
etag | strunowy | Etag powiązany z tym obiektem. |
contentDisposition | strunowy | Dyspozycja zawartości powiązana z tym obiektem. |
contentEncoding | strunowy | Kodowanie treści skojarzone z tym obiektem. |
contentLanguage | strunowy | Język zawartości powiązany z tym obiektem. |
contentType | strunowy | Typ zawartości skojarzony z tym obiektem. |
metadata | map<łańcuch, ciąg> | Pary klucz/wartość dodatkowych, określonych przez programistę niestandardowych metadanych. |
request.resource zawiera je wszystkie z wyjątkiem generation , metageneration , etag , timeCreated i updated .
Limity reguł bezpieczeństwa
Podczas pracy z regułami bezpieczeństwa należy zwrócić uwagę na następujące ograniczenia:
| Limit | Detale |
|---|---|
Maksymalna liczba firestore.exists() i firestore.get() na żądanie | 2 dla żądań pojedynczych dokumentów i zapytań. Przekroczenie tego limitu skutkuje błędem odmowy uprawnień. Wywołania dostępu do tych samych dokumentów mogą być buforowane, a wywołania buforowane nie wliczają się do limitów. |
Pełny przykład
Łącząc to wszystko razem, możesz stworzyć pełny przykład reguł dla rozwiązania do przechowywania obrazów:
service firebase.storage {
match /b/{bucket}/o {
match /images {
// Cascade read to any image type at any path
match /{allImages=**} {
allow read;
}
// Allow write files to the path "images/*", subject to the constraints:
// 1) File is less than 5MB
// 2) Content type is an image
// 3) Uploaded content type matches existing content type
// 4) File name (stored in imageId wildcard variable) is less than 32 characters
match /{imageId} {
allow write: if request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*')
&& request.resource.contentType == resource.contentType
&& imageId.size() < 32
}
}
}
}
Baza danych czasu rzeczywistego
Podstawowa struktura
W bazie danych czasu rzeczywistego reguły bezpieczeństwa Firebase składają się z wyrażeń podobnych do języka JavaScript zawartych w dokumencie JSON.
Używają następującej składni:
{
"rules": {
"<<path>>": {
// Allow the request if the condition for each method is true.
".read": <<condition>>,
".write": <<condition>>,
".validate": <<condition>>
}
}
}
Reguła zawiera trzy podstawowe elementy:
- Ścieżka: Lokalizacja bazy danych. Odzwierciedla to strukturę JSON Twojej bazy danych.
- Żądanie: Są to metody używane przez regułę do udzielania dostępu. Reguły
readiwritezapewniają szeroki dostęp do odczytu i zapisu, podczas gdy regułyvalidatedziałają jako dodatkowa weryfikacja w celu przyznania dostępu na podstawie przychodzących lub istniejących danych. - Warunek: Warunek zezwalający na żądanie, jeśli ma ono wartość prawda.
Jak zasady odnoszą się do ścieżek
W bazie danych czasu rzeczywistego reguły są stosowane atomowo, co oznacza, że reguły w węzłach nadrzędnych wyższego poziomu zastępują reguły w bardziej szczegółowych węzłach podrzędnych, a reguły w węźle głębszym nie mogą przyznać dostępu do ścieżki nadrzędnej. Nie możesz udoskonalić ani cofnąć dostępu do głębszej ścieżki w strukturze bazy danych, jeśli już ją przyznałeś dla jednej ze ścieżek nadrzędnych.
Rozważ następujące zasady:
{
"rules": {
"foo": {
// allows read to /foo/*
".read": "data.child('baz').val() === true",
"bar": {
// ignored, since read was allowed already
".read": false
}
}
}
}
Ta struktura zabezpieczeń umożliwia odczyt /bar/ z każdego przypadku, gdy /foo/ zawiera baz potomną o wartości true . Reguła ".read": false w /foo/bar/ nie ma tu żadnego wpływu, ponieważ dostępu nie można cofnąć za pomocą ścieżki potomnej.
Chociaż może nie wydawać się to natychmiast intuicyjne, jest to potężna część języka reguł i pozwala na wdrożenie bardzo złożonych uprawnień dostępu przy minimalnym wysiłku. Jest to szczególnie przydatne w przypadku zabezpieczeń opartych na użytkownikach .
Jednak reguły .validate nie nakładają się kaskadowo. Wszystkie reguły sprawdzania poprawności muszą być spełnione na wszystkich poziomach hierarchii, aby zapis był dozwolony.
Ponadto, ponieważ reguły nie mają zastosowania z powrotem do ścieżki nadrzędnej, operacja odczytu lub zapisu kończy się niepowodzeniem, jeśli w żądanej lokalizacji lub w lokalizacji nadrzędnej nie ma reguły, która przyznaje dostęp. Nawet jeśli każda ścieżka podrzędna, której dotyczy problem, jest dostępna, odczyt w lokalizacji nadrzędnej zakończy się całkowitym niepowodzeniem. Rozważ tę strukturę:
{
"rules": {
"records": {
"rec1": {
".read": true
},
"rec2": {
".read": false
}
}
}
}
Bez zrozumienia, że reguły są oceniane atomowo, mogłoby się wydawać, że pobranie ścieżki /records/ zwróci rec1 , ale nie rec2 . Rzeczywisty wynik jest jednak błędem:
JavaScript
var db = firebase.database();
db.ref("records").once("value", function(snap) {
// success method is not called
}, function(err) {
// error callback triggered with PERMISSION_DENIED
});
Cel C
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
// success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
// cancel block triggered with PERMISSION_DENIED
}];
Szybki
var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
// success block is not called
}, withCancelBlock: { error in
// cancel block triggered with PERMISSION_DENIED
})
Jawa
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot snapshot) {
// success method is not called
}
@Override
public void onCancelled(FirebaseError firebaseError) {
// error callback triggered with PERMISSION_DENIED
});
});
ODPOCZYNEK
curl https://docs-examples.firebaseio.com/rest/records/ # response returns a PERMISSION_DENIED error
Ponieważ operacja odczytu w /records/ jest niepodzielna i nie ma reguły odczytu, która zapewnia dostęp do wszystkich danych w /records/ , spowoduje to błąd PERMISSION_DENIED . Jeśli ocenimy tę regułę w symulatorze bezpieczeństwa w naszej konsoli Firebase , zobaczymy, że operacja odczytu została odrzucona:
Attempt to read /records with auth=Success(null)
/
/records
No .read rule allowed the operation.
Read was denied.
Operacja została odrzucona, ponieważ żadna reguła odczytu nie zezwalała na dostęp do ścieżki /records/ , ale pamiętaj, że reguła dla rec1 nigdy nie została oceniona, ponieważ nie znajdowała się w ścieżce, o którą prosiliśmy. Aby pobrać rec1 , musielibyśmy uzyskać do niego bezpośredni dostęp:
JavaScript
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
// SUCCESS!
}, function(err) {
// error callback is not called
});
Cel C
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
// SUCCESS!
}];
Szybki
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
// SUCCESS!
})
Jawa
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot snapshot) {
// SUCCESS!
}
@Override
public void onCancelled(FirebaseError firebaseError) {
// error callback is not called
}
});
ODPOCZYNEK
curl https://docs-examples.firebaseio.com/rest/records/rec1 # SUCCESS!
Zmienna lokalizacji
Reguły bazy danych czasu rzeczywistego obsługują zmienną $location w celu dopasowania segmentów ścieżki. Użyj przedrostka $ przed segmentem ścieżki, aby dopasować regułę do dowolnych węzłów podrzędnych na ścieżce.
{
"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')"
}
}
}
}
}
Możesz także użyć $variable równolegle ze stałymi nazwami ścieżek.
{
"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 }
}
}
}