Jak działają reguły bezpieczeństwa

Bezpieczeństwo może być jednym z najbardziej złożonych elementów układanki tworzenia aplikacji. W przypadku większości aplikacji programiści muszą zbudować i uruchomić serwer obsługujący uwierzytelnianie (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ślenie uprawnień opartych na ścieżce dla klientów łączących się bezpośrednio z Twoimi danymi. Skorzystaj z tego przewodnika, aby dowiedzieć się więcej o stosowaniu reguł do żądań przychodzących.

Wybierz produkt, aby dowiedzieć się więcej o jego zasadach.

Chmura Firestore

Podstawowa struktura

Reguły bezpieczeństwa Firebase w Cloud Firestore i Cloud Storage korzystają z następującej struktury 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ł należy zrozumieć następujące kluczowe pojęcia:

  • Żądanie: Metoda lub metody wywoływane w instrukcji allow . Są to metody, którym pozwalasz na uruchamianie. Standardowe metody to: get , list , create , update i delete . Wygodne metody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce przechowywania.
  • Ścieżka: lokalizacja bazy danych lub przechowywania reprezentowana jako ścieżka URI.
  • Reguła: allow zezwalająca zawierająca warunek zezwalający na żądanie, jeśli ma ono wartość true.

Reguły bezpieczeństwa wersja 2

Od maja 2019 r. dostępna jest już wersja 2 reguł bezpieczeństwa Firebase. Wersja 2 reguł zmienia zachowanie rekurencyjnych symboli wieloznacznych {name=**} . Jeśli planujesz używać zapytań dotyczących grup kolekcji, musisz użyć wersji 2. Musisz wyrazić zgodę na wersję 2, wprowadzając rules_version = '2'; pierwsza linia reguł bezpieczeństwa:

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

Pasujące ścieżki

Wszystkie instrukcje dopasowania powinny wskazywać na dokumenty, a nie kolekcje. Instrukcja match może wskazywać konkretny dokument, jak w przypadku match /cities/SF lub używać symboli wieloznacznych, aby wskazywać dowolny dokument w określonej ścieżce, jak w przypadku match /cities/{city} .

W powyższym przykładzie instrukcja match używa składni wieloznacznej {city} . Oznacza to, że reguła dotyczy dowolnego dokumentu w kolekcji cities , takiego jak /cities/SF lub /cities/NYC . Po ocenie wyrażeń allow w instrukcji match zmienna city zostanie zamieniona na nazwę 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 podzbiory. Ważne jest, aby zrozumieć, w jaki sposób reguły bezpieczeństwa współdziałają z danymi hierarchicznymi.

Rozważmy sytuację, w której każdy dokument w kolekcji cities zawiera podkolekcję landmarks . Reguły bezpieczeństwa obowiązują tylko na dopasowanej ścieżce, więc kontrola dostępu zdefiniowana w kolekcji cities nie ma zastosowania do podkolekcji landmarks . Zamiast tego napisz jawne 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 określana względem ścieżki zewnętrznej instrukcji match . Dlatego następujące zestawy reguł są 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 wieloznacznej, {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 stosowania 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 kolekcji podrzędnej. Na przykład reguły wymienione powyżej będą pasować do dokumentu znajdującego się w /cities/SF/landmarks/coit_tower , a wartość zmiennej document będzie wynosić 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 korzystają z wersji 1. W wersji 1 rekursywne symbole wieloznaczne dopasowują jeden lub więcej elementów ścieżki. Nie odpowiadają one pustej ścieżce, więc match /cities/{city}/{document=**} dopasowuje dokumenty w podkolekcjach, ale nie w kolekcji cities , natomiast match /cities/{document=**} dopasowuje oba dokumenty w kolekcji kolekcja i podkolekcja cities .

Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.

Wersja 2

W wersji 2 reguł bezpieczeństwa rekurencyjne symbole wieloznaczne dopasowują zero lub więcej elementów ścieżki. match/cities/{city}/{document=**} dopasowuje dokumenty w dowolnych podkolekcjach, a także dokumenty w kolekcji cities .

Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2'; na górze 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>;
    }
  }
}

Na instrukcję dopasowania możesz mieć maksymalnie jeden rekurencyjny symbol wieloznaczny, 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>;
    }
  }
}

Jeśli używasz zapytań do grup kolekcji , musisz użyć wersji 2, zobacz zabezpieczanie zapytań do grup kolekcji .

Nakładające się instrukcje dopasowania

Możliwe jest, że dokument będzie pasował do więcej niż jednej instrukcji match . W przypadku, gdy do żądania pasuje wiele wyrażeń allow , dostęp jest dozwolony, jeśli true jest którykolwiek z warunków:

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ą dozwolone, ponieważ druga reguła jest zawsze true , nawet jeśli pierwsza reguła jest zawsze false .

Limity reguł bezpieczeństwa

Pracując z regułami bezpieczeństwa, należy zwrócić uwagę na następujące ograniczenia:

Limit Detale
Maksymalna liczba wywołań exists() , get() i getAfter() na żądanie
  • 10 w przypadku żądań pojedynczych dokumentów i zapytań.
  • 20 dla odczytów wielu dokumentów, transakcji i zapisów wsadowych. Do każdej operacji obowiązuje również poprzedni limit 10.

    Załóżmy na przykład, że tworzysz zbiorcze żądanie zapisu z 3 operacjami zapisu i że Twoje reguły bezpieczeństwa korzystają z 2 wywołań dostępu do dokumentu w celu sprawdzenia każdego zapisu. W tym przypadku każdy zapis wykorzystuje 2 z 10 wywołań dostępu, a zbiorcze żądanie zapisu wykorzystuje 6 z 20 wywołań dostępu.

Przekroczenie któregokolwiek z limitów powoduje błąd 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 przechwytujących ścieżkę 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 wywołań funkcji rekurencyjnych lub cyklicznych 0 (niedozwolone)
Maksymalna liczba wyrażeń ocenianych na żądanie 1000
Maksymalny rozmiar zestawu reguł Zestawy reguł muszą przestrzegać dwóch ograniczeń rozmiaru:
  • limit 256 KB rozmiaru źródła tekstu zestawu reguł publikowanego z konsoli Firebase lub z interfejsu CLI przy użyciu firebase deploy .
  • limit 250 KB rozmiaru skompilowanego zestawu reguł, który powstaje, gdy Firebase przetwarza źródło i aktywuje je na zapleczu.

Magazyn w chmurze

Podstawowa struktura

Reguły bezpieczeństwa Firebase w Cloud Firestore i Cloud Storage korzystają z następującej struktury 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ł należy zrozumieć następujące kluczowe pojęcia:

  • Żądanie: Metoda lub metody wywoływane w instrukcji allow . Są to metody, którym pozwalasz na uruchamianie. Standardowe metody to: get , list , create , update i delete . Wygodne metody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce przechowywania.
  • Ścieżka: lokalizacja bazy danych lub przechowywania reprezentowana jako ścieżka URI.
  • Reguła: allow zezwalająca zawierająca warunek zezwalający na żądanie, jeśli ma ono wartość true.

Pasujące ścieżki

Reguły zabezpieczeń Cloud Storage match ścieżkami plików używanymi do uzyskiwania dostępu do plików w Cloud Storage. Reguły mogą match dokładne ścieżki lub ścieżki z symbolami wieloznacznymi, a reguły mogą być również zagnieżdżane. Jeśli żadna reguła dopasowania nie zezwala na metodę żądania lub warunek ma wartość false , żądanie zostaje odrzucone.

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

Dopasowania z dziką kartą

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

Symbol wieloznaczny tworzy się poprzez dodanie nawiasów klamrowych wokół nazwy symbolu wieloznacznego, np {string} . Wielosegmentowy symbol wieloznaczny można zadeklarować, dodając =** do nazwy 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ł, 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 którykolwiek condition lub other_condition ma wartość true, podczas gdy plik „images/users/user:12345/profilePhoto.png” podlega jedynie wynikowi other_condition .

Do zmiennej wieloznacznej można odwoływać się w ramach 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 zabezpieczeń 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 usunięcia są oceniane na podstawie request wysyłanego do Cloud Storage. Zmienna request zawiera ścieżkę pliku, w którym żądanie jest wykonywane, godzinę otrzymania żądania i nową wartość resource , jeśli żądanie jest zapisem. Uwzględnione są także nagłówki HTTP i stan uwierzytelniania.

Obiekt request zawiera także unikalny identyfikator użytkownika i ładunek Firebase Authentication w obiekcie request.auth , co zostanie wyjaśnione w dalszej części dokumentacji, w sekcji Uwierzytelnianie .

Pełna lista właściwości w obiekcie request dostępna jest poniżej:

Nieruchomość Typ Opis
auth mapa<ciąg, ciąg> Gdy użytkownik jest zalogowany, podaje uid , unikalny identyfikator użytkownika i token , czyli mapę roszczeń JWT uwierzytelniania Firebase. W przeciwnym razie będzie null .
params mapa<ciąg, ciąg> Mapa zawierająca parametry zapytania żądania.
path ścieżka path reprezentująca ścieżkę, na której wykonywane jest żądanie.
resource mapa<ciąg, ciąg> Nowa wartość zasobu, obecna tylko w żądaniach write .
time znak czasu Znacznik czasu reprezentujący czas serwera, w którym oceniane jest żądanie.

Ocena zasobów

Oceniając reguły, możesz także chcieć ocenić metadane przesyłanego, pobieranego, modyfikowanego lub usuwanego pliku. Umożliwia to tworzenie złożonych i potężnych reguł, które na przykład zezwalają 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 wyświetlanych w obiekcie Cloud Storage. Właściwości te można sprawdzić w żądaniach 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 istniejącego aktualnie w ścieżce żądania, masz także możliwość wykorzystania obiektu request.resource , który zawiera podzbiór metadanych pliku, który ma zostać zapisany, 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 dostępna jest poniżej:

Nieruchomość Typ Opis
name strunowy Pełna nazwa obiektu
bucket strunowy Nazwa segmentu, w którym znajduje się ten obiekt.
generation wew Generowanie obiektu Google Cloud Storage dla tego obiektu.
metageneration wew Metageneracja obiektu Google Cloud Storage dla tego obiektu.
size wew Rozmiar obiektu w bajtach.
timeCreated znak czasu Znacznik czasu reprezentujący czas utworzenia obiektu.
updated znak czasu Znacznik czasu reprezentujący czas ostatniej aktualizacji obiektu.
md5Hash strunowy Hash MD5 obiektu.
crc32c strunowy Hash crc32c obiektu.
etag strunowy Etag powiązany z tym obiektem.
contentDisposition strunowy Dyspozycja treści powiązana z tym obiektem.
contentEncoding strunowy Kodowanie treści powiązane z tym obiektem.
contentLanguage strunowy Język treści powiązany z tym obiektem.
contentType strunowy Typ zawartości powiązany z tym obiektem.
metadata mapa<ciąg, ciąg> Pary klucz/wartość dodatkowych, niestandardowych metadanych określonych przez programistę.

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

Limity reguł bezpieczeństwa

Pracując 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 powoduje błąd 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, 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ń przypominających 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 składa się z trzech podstawowych elementów:

  • Ś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 read i write zapewniają szeroki dostęp do odczytu i zapisu, natomiast reguły validate działają jako dodatkowa weryfikacja w celu przyznania dostępu na podstawie przychodzących lub istniejących danych.
  • Warunek: Warunek, który zezwala na żądanie, jeśli ma wartość true.

Jak reguły odnoszą się do ścieżek

W Realtime Database reguły obowiązują niepodzielnie, 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 położonym głębiej nie mogą udzielić dostępu do ścieżki nadrzędnej. Nie możesz uściślić ani odwołać dostępu do głębszej ścieżki w strukturze bazy danych, jeśli został już przyznany 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/ za każdym razem, gdy /foo/ zawiera baz podrzędną o wartości true . ".read": false w /foo/bar/ nie ma tutaj żadnego efektu, ponieważ ścieżka podrzędna nie może odwołać dostępu.

Chociaż może nie wydawać się to od razu 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 bezpieczeństwa opartego na użytkownikach .

Jednakże reguły .validate nie działają kaskadowo. Aby zapis był dozwolony, wszystkie reguły sprawdzania poprawności muszą być spełnione na wszystkich poziomach hierarchii.

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 zapewnia dostęp. Nawet jeśli dostępna jest każda ścieżka podrzędna, której dotyczy problem, 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, może 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
Uwaga: ten produkt Firebase nie jest dostępny w docelowym klipie aplikacji.
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
Uwaga: ten produkt Firebase nie jest dostępny w docelowym klipie 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
})
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łaby dostęp do wszystkich danych w /records/ , spowoduje to wyświetlenie błędu 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 należy pamiętać, że reguła dla rec1 nigdy nie została oceniona, ponieważ nie znajdowała się ona w żądanej ścieżce. 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
Uwaga: ten produkt Firebase nie jest dostępny w docelowym klipie aplikacji.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
Szybki
Uwaga: ten produkt Firebase nie jest dostępny w docelowym klipie aplikacji.
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 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')"
          }
        }
      }
    }
  }

Można także używać $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 }
      }
    }
  }