Jak działają reguły zabezpieczeń

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ą utworzyć i uruchomić serwer, obsługuje uwierzytelnianie (to, kim jest użytkownik) i autoryzację (co użytkownik może robić).

Firebase Security Rules usunąć pośrednią warstwę (serwer) i umożliwić klientom, które łączą się bezpośrednio z Twoimi danymi, określanie uprawnień na podstawie ścieżki. Skorzystaj z tego przewodnika, aby: Dowiedz się więcej o sposobie stosowania reguł do żądań przychodzących.

Wybierz produkt, aby dowiedzieć się więcej o jego regułach.

Cloud Firestore

Podstawowa struktura

Firebase Security Rules w Cloud Firestore i Cloud Storage mają następującą strukturę i składnia:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Podczas tworzenia reguł warto znać te kluczowe pojęcia:

• Request: metoda lub metody wywołane w instrukcji allow. Są to które możesz uruchamiać. Standardowe metody to: get, list, create, update i delete. Metody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce magazynu.
• Ścieżka: baza danych lub lokalizacja pamięci masowej reprezentowana przez Ścieżka identyfikatora URI.
• Reguła: instrukcja allow zawierająca warunek, który pozwala na jeśli zwraca wartość prawda.

Reguły zabezpieczeń w wersji 2

Od maja 2019 r. reguła zabezpieczeń Firebase jest w wersji 2 i dostępności informacji. Wersja 2 reguł zmienia działanie rekursywnych zaimków {name=**}. Musisz używać wersji 2, jeśli planujesz używać zapytań dotyczących grup kolekcji. Musisz wyrazić zgodę na wersji 2, ustawiając rules_version = '2'; jako pierwszy wiersz w zabezpieczeniach reguły:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Pasujące ścieżki

Wszystkie instrukcje dopasowania powinny wskazywać dokumenty, a nie kolekcje. Dopasowanie instrukcja może wskazywać konkretny dokument, na przykład match /cities/SF, lub użyć symboli wieloznacznych na dowolny dokument w określonej ścieżce, np. match /cities/{city}.

W powyższym przykładzie instrukcja dopasowania używa składni zastępnika {city}. Oznacza to, że reguła ma zastosowanie do wszystkich dokumentów w kolekcji cities, na przykład /cities/SF lub /cities/NYC. Gdy wyrażenia allow w instrukcji dopasowania to analizowana, zmienna city przyjmie nazwę dokumentu miasta, na przykład SF lub NYC.

Uwaga: możesz uzyskać dostęp tylko do dokumentów, na które zezwalają Twoje reguły zabezpieczeń. dostęp. Na przykład reguły pokazane powyżej zezwalają na dostęp tylko do dokumentów w kolekcji cities. W rezultacie blokują one również dostęp do dokumentów we wszystkich innych kolekcjach.

Pasujące kolekcje podrzędne

Dane w Cloud Firestore są porządkowane w kolekcji dokumentów, a każdy dokument może rozszerzać hierarchię za pomocą podkolekcji. Ważne jest, Dowiedz się, jak reguły zabezpieczeń współdziałają z danymi hierarchicznymi.

Wyobraź sobie sytuację, w której każdy dokument w kolekcji cities zawiera podkolekcję landmarks. Reguły zabezpieczeń są stosowane tylko w przypadku dopasowanej ścieżki, więc kontrole dostępu zdefiniowane w kolekcji cities nie mają zastosowania do landmarks kolekcja podrzędna. Zamiast tego utwórz jawne reguły, aby kontrolować dostęp do podzbiorów:

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>;
      }
    }
  }
}

Gdy zagnieżdżasz instrukcje match, ścieżka wewnętrznej instrukcji match wynosi zawsze w stosunku do ścieżki zewnętrznej instrukcji match. Te zestawy reguł są więc 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 były stosowane do dowolnie głębszej hierarchii, użyj funkcji składnia rekurencyjnego symbolu wieloznacznego, {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>;
    }
  }
}

Jeśli używasz składni rekurencyjnego symbolu wieloznacznego, zmienna z symbolem wieloznacznym będzie zawierać parametr całego pasującego segmentu ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonym podkolekcja. Na przykład wymienione powyżej reguły będą pasować dokumentu znajdującego się pod adresem /cities/SF/landmarks/coit_tower, a wartość zmienna document będzie miała wartość SF/landmarks/coit_tower.

Pamiętaj jednak, że działanie rekurencyjnych symboli wieloznacznych zależy od reguł wersji.

Wersja 1

Reguły zabezpieczeń używają domyślnie wersji 1. w wersji 1 rekurencyjne symbole wieloznaczne; pasują do co najmniej jednego elementu ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**} pasuje do dokumentów w podkolekcjach, ale nie w kolekcji cities, podczas gdy match /cities/{document=**} pasuje do dokumentów w kolekcji cities i podkolekcjach.

Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu oświadczenia o dopasowaniu.

Wersja 2

W wersji 2 reguł zabezpieczeń rekurencyjne symbole wieloznaczne pasują do 0 lub większej liczby ścieżek elementy(ów). match/cities/{city}/{document=**} pasuje do dokumentów w dowolnym podzbiorów oraz dokumentów z kolekcji cities.

Musisz zaakceptować wersję 2, dodając rules_version = '2'; u góry Twoje reguły zabezpieczeń:

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 użyć maksymalnie 1 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 cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

Jeśli używasz zapytań dotyczących grup kolekcji, musisz stosować parametry w wersji 2 znajdziesz informacje na temat zabezpieczania zapytań dotyczących grup kolekcji.

Nakładające się instrukcje dopasowania

Dokument może pasować 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 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 w kolekcji cities będą jest dozwolona, ponieważ druga reguła ma zawsze wartość true, mimo że pierwsza ma zawsze wartość false.

Limity reguł zabezpieczeń

Podczas pracy z regułami zabezpieczeń pamiętaj o tych ograniczeniach:

Limit	Szczegóły
Maksymalna liczba wywołań exists(), get() i getAfter() na żądanie	10 w przypadku żądań pojedynczych dokumentów i zapytań. 20 w przypadku odczytów wielu dokumentów, transakcji, i zapisy wsadowe. Poprzedni limit 10 obowiązuje również w przypadku . Wyobraź sobie na przykład, że tworzysz wsadowe żądanie zapisu za pomocą 3 operacje zapisu i reguły zabezpieczeń używane w 2 dokumentach dostępu do wywołań, aby zweryfikować każdy zapis. W tym przypadku każdy zapis używa 2 z 10 wywołań dostępu i zbiorcze żądanie zapisu używa 6 z 20 wywołań dostępu. Przekroczenie któregokolwiek z tych limitów powoduje błąd dotyczący braku uprawnień. Niektóre wywołania dostępu do dokumentów mogą być przechowywane w pamięci podręcznej, i połączenia z pamięci podręcznej nie wliczają się do tych limitów.
Maksymalna głębokość zagnieżdżonej instrukcji match	10
Maksymalna długość ścieżki (w segmentach ścieżki) dozwolona w zbiorze ujęć match	100
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolona w zbiorze zagnieżdżone instrukcje match	20
Maksymalna głębokość wywołania funkcji	20
Maksymalna liczba argumentów funkcji	7
Maksymalna liczba powiązań zmiennych na funkcję (let)	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ć 2 limitów rozmiarów: Limit 256 KB dotyczący rozmiaru źródła tekstu zestawu reguł opublikowana z konsoli Firebase lub z interfejsu wiersza poleceń firebase deploy Limit 250 KB na rozmiar skompilowanego zestawu reguł, który generuje gdy Firebase przetworzy źródło i włączy je z backendu.

Cloud Storage

Podstawowa struktura

Firebase Security Rules w Cloud Firestore i Cloud Storage mają następującą strukturę i składnia:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Podczas tworzenia reguł warto znać te kluczowe pojęcia:

• Request: metoda lub metody wywołane w instrukcji allow. Są to które możesz uruchamiać. Standardowe metody to: get, list, create, update i delete. Metody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce magazynu.
• Ścieżka: baza danych lub lokalizacja pamięci masowej reprezentowana przez Ścieżka identyfikatora URI.
• Reguła: instrukcja allow zawierająca warunek, który pozwala na jeśli zwraca wartość prawda.

Pasujące ścieżki

Cloud Storage Security Rules match ścieżki do plików używane do uzyskiwania dostępu do plików w Cloud Storage. Reguły mogą match ścieżki ścisłe lub ścieżki z symbolami wieloznacznymi. również mogą być zagnieżdżone. Jeśli reguła „Brak dopasowania” zezwala na metodę żądania lub warunek zwraca wartość false, żądanie jest odrzucane.

Ścisłe 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>;
  }
}

Dopasowania z użyciem symboli wieloznacznych

Reguł można też używać do match wzorca za pomocą symboli wieloznacznych. Symbol wieloznaczny to nazwana zmienna reprezentująca pojedynczy ciąg, taki jak profilePhoto.png lub wiele segmentów ścieżki, np. images/profilePhoto.png

Symbol wieloznaczny tworzy się przez dodanie nawiasów klamrowych wokół nazwy, np. {string} Symbol wieloznaczny dla wielu segmentów można zadeklarować, dodając =** do nazwa symbolu wieloznacznego, np. {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ł, 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 powyżej podanych regułach plik „images/profilePhoto.png” może być odczytywany, jeśli albo condition, albo other_condition zwracają wartość „prawda”. Plik „images/users/user:12345/profilePhoto.png” jest natomiast odczytywany tylko wtedy, gdy other_condition zwraca wartość „prawda”.

Do zmiennej z symbolem wieloznacznym można się odwoływać z pliku udostępniania match autoryzacja nazwy lub ścieżki:

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

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.

Poproś o ocenę

Przesyłanie, pobieranie, zmiany metadanych i usuwanie są oceniane za pomocą request wysłanego do Cloud Storage. Zmienna request zawiera ścieżkę do pliku, w którym wykonywane jest żądanie, czas otrzymania żądania oraz nową wartość resource, jeśli żądanie dotyczy zapisu. Nagłówki HTTP i stan uwierzytelniania.

Obiekt request zawiera też unikalny identyfikator użytkownika i obiekt ładunek Firebase Authentication w obiekcie request.auth, który zostanie wyjaśniliśmy szerzej w sekcji Uwierzytelnianie. sekcji dokumentów.

Pełną listę właściwości obiektu request znajdziesz poniżej:

Właściwość	Typ	Opis
auth	mapa<ciąg, ciąg>	Gdy użytkownik jest zalogowany, podaje uid, jego unikalny identyfikator oraz unikalny identyfikator token, mapa deklaracji JWT (Firebase Authentication). W przeciwnym razie będzie tonull.
params	mapa<ciąg, ciąg>	Mapa zawierająca parametry zapytania żądania.
path	ścieżka	path reprezentujący ścieżkę, do której prowadzi żądanie wykonano na
resource	mapa<ciąg, ciąg>	Nowa wartość zasobu, obecna tylko w żądaniach write.
time	sygnatura czasowa	Sygnatura czasowa określająca czas oceny żądania przez serwer.

Uwaga: szczegółowa dokumentacja tych usług jest dostępna w Firebase Security Rules dla interfejsu API Cloud Storage odniesienie.

Ocena zasobów

Oceniając reguły, warto też przeanalizować metadane pliku przesyłania, pobierania, modyfikowania lub usuwania. Dzięki temu możesz tworzyć złożone i skuteczne reguły, które zezwalają na używanie tylko plików o określonych parametrach. typów treści, które mają być przesyłane, lub tylko pliki większe niż określony rozmiar Usunięto.

Parametr Firebase Security Rules dla Cloud Storage zawiera metadane pliku w tagu resource który zawiera pary klucz-wartość metadanych wyświetlanych w tagu Cloud Storage obiekt. Te właściwości można sprawdzić w prośbach read lub write, aby zapewnić integralność danych.

W przypadku żądań write (takich jak przesyłanie, aktualizowanie metadanych i usuwanie) oprócz obiektu resource, który zawiera metadane pliku znajdującego się obecnie na ścieżce żądania, możesz też użyć obiektu request.resource, który zawiera podzbiór metadanych pliku do zapisania, jeśli zapis jest dozwolony. Możesz użyć tych 2 wartości, aby zapewnić integralność danych lub zastosować ograniczenia aplikacji, takie jak typ lub rozmiar pliku.

Pełną listę właściwości obiektu resource znajdziesz poniżej:

Właściwość	Typ	Opis
name	ciąg znaków	Pełna nazwa obiektu.
bucket	ciąg znaków	Nazwa zasobnika, w którym znajduje się ten obiekt.
generation	int,	Google Cloud Storagegeneracja obiektu tego obiektu.
metageneration	int,	Google Cloud Storage przez metagenerację tego obiektu.
size	int,	Rozmiar obiektu w bajtach.
timeCreated	sygnatura czasowa	Sygnatura czasowa określająca czas utworzenia obiektu.
updated	sygnatura czasowa	Sygnatura czasowa określająca, kiedy obiekt został ostatnio zaktualizowany.
md5Hash	ciąg znaków	Skrót MD5 obiektu.
crc32c	ciąg znaków	Skrót crc32c obiektu.
etag	ciąg znaków	ETag powiązany z tym obiektem.
contentDisposition	ciąg znaków	Dyspozycja treści powiązana z tym obiektem.
contentEncoding	ciąg znaków	Kodowanie treści powiązane z tym obiektem.
contentLanguage	ciąg znaków	Język treści powiązany z tym obiektem.
contentType	ciąg znaków	Typ treści powiązany z tym obiektem.
metadata	mapa<ciąg, ciąg>	Pary klucz-wartość dodatkowych metadanych niestandardowych określonych przez dewelopera.

request.resource zawiera wszystkie te elementy z wyjątkiem generation, metageneration, etag, timeCreated i updated.

Uwaga: szczegółową dokumentację tych usług znajdziesz w Firebase Security Rules (dokumentacja interfejsu API Cloud Storage).

Limity reguł zabezpieczeń

Podczas pracy z regułami zabezpieczeń pamiętaj o tych ograniczeniach:

Limit	Szczegóły
Maksymalna liczba wartości firestore.exists() i firestore.get() wywołań na żądanie	2 – żądania dotyczące pojedynczego dokumentu i zapytania. Przekroczenie tego limitu powoduje błąd braku uprawnień. Wywołania dostępu do tych samych dokumentów mogą być przechowywane w pamięci podręcznej, a wywołania z pamięci podręcznej nie wliczają się do limitów.

Pełny przykład

Łącząc wszystkie te elementy, możesz utworzyć 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
     }
   }
 }
}

Realtime Database

Podstawowa struktura

W Realtime Database ciąg Firebase Security Rules składa się z wyrażeń podobnych do JavaScriptu zawartych w Dokument JSON.

Mają taką składnię:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Reguła składa się z 3 podstawowych elementów:

• Ścieżka: lokalizacja bazy danych. Powoduje to odzwierciedlenie struktury JSON bazy danych.
• Żądanie: to metody, których reguła używa do przyznawania dostępu. Reguły read i write przyznają szeroki dostęp do odczytu i zapisu, a reguły validate pełnią rolę weryfikacji dodatkowej, przyznając dostęp na podstawie danych przychodzących lub istniejących.
• Warunek:warunek, który zezwala na żądanie, o ile jego wartość to prawda.

Jak reguły mają zastosowanie do ścieżek

W Realtime Database Rules obowiązują atomowo, co oznacza, że reguły na węzłów nadrzędnych wyższego poziomu zastępują reguły na bardziej szczegółowych węzłach podrzędnych, reguły na głębszym węźle nie mogą przyznawać dostępu do ścieżki nadrzędnej. Ty nie możesz zawęzić lub unieważnić dostępu na głębszej ścieżce w strukturze bazy danych, jeśli Został już przez Ciebie przydzielony dla jednej ze ścieżek nadrzędnych.

Weź pod uwagę te reguły:

{
  "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 z /bar/ w dowolnym momencie /foo/ zawiera element podrzędny baz o wartości true. Reguła ".read": false w regule /foo/bar/ nie ma ponieważ dostęp nie może zostać unieważniony przez ścieżkę podrzędną.

Chociaż może się to wydawać nieintuicyjne, jest to potężna część języka reguł, która umożliwia wdrażanie bardzo złożonych uprawnień dostępu z minimalnym wysiłkiem. Jest to szczególnie przydatne w przypadku zabezpieczeń opartych na użytkownikach.

Jednak reguły .validate nie działają kaskadowo. Wszystkie reguły weryfikacji musi być spełnione na wszystkich poziomach hierarchii, aby zapis był dozwolony.

Poza tym reguły nie mają zastosowania do ścieżki nadrzędnej, więc nie są odczytywane ani zapisywane operacja kończy się niepowodzeniem, jeśli nie ma reguły w żądanej lokalizacji lub w elemencie nadrzędnym z której możesz korzystać. Nawet jeśli każda ścieżka podrzędna, której dotyczy problem, jest dostępna, w lokalizacji nadrzędnej nie uda się całkowicie. Weźmy pod uwagę tę strukturę:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

Może się wydawać, że bez zrozumienia reguł np. pobieranie ś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
});

Objective-C

Uwaga: ta usługa Firebase nie jest dostępna w przypadku celu typu App Clip.

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
}];

Swift

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

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
})

Java

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
  });
});

REST

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

Operacja odczytu w /records/ jest niepodzielna i nie ma reguły odczytu, która przyznała dostęp do wszystkich danych w elemencie /records/, dlatego spowoduje to wystąpienie błędu PERMISSION_DENIED. Jeśli ocenimy tę regułę w symulatorze zabezpieczeń w 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 dostępu do odczytu nie zezwalała na dostęp do ścieżki /records/. Pamiętaj, że reguła dla ścieżki rec1 nigdy nie została zweryfikowana, ponieważ nie znajdowała się na ścieżce, której dotyczyło żądanie. Aby pobrać plik rec1, musimy 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
});

Objective-C

Uwaga: ta usługa Firebase nie jest dostępna w przypadku celu typu App Clip.

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

Swift

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

Java

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
  }
});

REST

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Zmienna lokalizacji

Realtime Database Rules obsługuje $location , aby dopasować segmenty ścieżki. Na początku ścieżki użyj prefiksu $ segment, aby dopasować regułę do wszystkich 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')"
          }
        }
      }
    }
  }

Funkcji $variable można też używać równolegle ze stałą ścieżką nazw.

  {
    "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 }
      }
    }
  }