Jak działają reguły zabezpieczeń

Bezpieczeństwo może być jednym z najtrudniejszych elementów układanki związanej z tworzeniem aplikacji. W większości aplikacji deweloperzy muszą utworzyć i uruchomić serwer, który obsługuje uwierzytelnianie (określanie tożsamości użytkownika) i autoryzację (określanie, co użytkownik może robić).

Firebase Security Rules usunąć środkową warstwę (serwer) i umożliwić określanie uprawnień opartych na ścieżkach dla klientów, którzy łączą się bezpośrednio z Twoimi danymi. Z tego przewodnika dowiesz się więcej o tym, jak reguły są stosowane do żądań przychodzących.

Wybierz usługę, aby dowiedzieć się więcej o jej zasadach.

Cloud Firestore

Podstawowa struktura

Firebase Security Rules w Cloud Firestore i Cloud Storage używa tej 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ł warto znać te kluczowe pojęcia:

  • Żądanie: metoda lub metody wywoływane w instrukcji allow. To metody, które możesz uruchamiać. Standardowe metody to: get, list, create, update i delete. Metody wygody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce do pamięci.
  • Ścieżka: lokalizacja bazy danych lub pamięci masowej przedstawiona jako ścieżka URI.
  • Reguła: instrukcja allow, która zawiera warunek zezwalający na żądanie, jeśli jego wartość to prawda.

Reguły zabezpieczeń w wersji 2

Od maja 2019 roku dostępna jest wersja 2 Firebase reguł zabezpieczeń. Wersja 2 reguł zmienia działanie rekursywnych symboli wieloznacznych {name=**}. Jeśli planujesz używać zapytań dotyczących grup kolekcji, musisz użyć wersji 2. Aby włączyć wersję 2, musisz umieścić rules_version = '2'; w pierwszym wierszu reguł bezpieczeństwa:

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

Pasujące ścieżki

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

W przykładzie instrukcja match używa składni symbolu wieloznacznego {city}. Oznacza to, że reguła ma zastosowanie do każdego dokumentu w kolekcji cities, np. /cities/SF lub /cities/NYC. Gdy allow wyrażenia w instrukcji dopasowania zostaną obliczone, zmienna city zostanie przekształcona w nazwę dokumentu miasta, np. SF lub NYC.

.

Pasujące podkolekcje

Dane w Cloud Firestore są uporządkowane w kolekcje dokumentów, a każdy dokument może rozszerzać hierarchię za pomocą podkolekcji. Ważne jest, aby zrozumieć, jak reguły zabezpieczeń działają w przypadku danych hierarchicznych.

Rozważ sytuację, w której każdy dokument w kolekcji cities zawiera podkolekcję landmarks. Reguły zabezpieczeń mają zastosowanie tylko do pasującej ścieżki, więc kontrola dostępu zdefiniowana w kolekcji cities nie ma zastosowania do podkolekcji landmarks. Zamiast tego napisz 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>;
      }
    }
  }
}

Podczas zagnieżdżania instrukcji match ścieżka wewnętrznej instrukcji match jest zawsze względna w stosunku do ścieżki zewnętrznej instrukcji match. Te 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>;
    }
  }
}

Nakładające się instrukcje dopasowania

Dokument może pasować do więcej niż 1 match. Jeśli z żądaniem pasuje kilka 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.
    match /cities/{document} {
      allow read, write: if true;
    }
  }
}

W tym przykładzie wszystkie odczyty i zapisy w kolekcji cities będą dozwolone, ponieważ druga reguła zawsze ma wartość true, mimo że pierwsza reguła zawsze ma wartość false.

Rekurencyjne symbole wieloznaczne

Jeśli chcesz, aby reguły miały zastosowanie do dowolnie głębokiej hierarchii, użyj rekursywnej składni 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>;
    }
  }
}

Gdy używasz rekursywnej składni symbolu wieloznacznego, zmienna symbolu wieloznacznego 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 wymienione reguły będą pasować do dokumentu znajdującego się w lokalizacji /cities/SF/landmarks/coit_tower, a wartość zmiennej document będzie wynosić SF/landmarks/coit_tower.

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

Wersja 1

Reguły zabezpieczeń domyślnie korzystają z wersji 1. W wersji 1 rekursywne symbole wieloznaczne pasują do co najmniej 1 elementu ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**} pasuje do dokumentów w kolekcjach podrzędnych, ale nie w cities kolekcji, natomiast match /cities/{document=**} pasuje do dokumentów w cities kolekcji i kolekcjach podrzędnych.

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

Wersja 2

W wersji 2 reguł bezpieczeństwa rekursywne symbole wieloznaczne pasują do zera lub większej liczby elementów ścieżki. Symbol match/cities/{city}/{document=**} pasuje do dokumentów w dowolnych podkolekcjach, a także do dokumentów w kolekcji match/cities/{city}/{document=**}.cities

Aby włączyć wersję 2, musisz dodać rules_version = '2'; na początku reguł 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>;
    }
  }
}

W każdym wyrażeniu dopasowania możesz użyć maksymalnie jednego rekursywnego symbolu wieloznacznego, ale w wersji 2 możesz go umieścić w dowolnym miejscu wyrażenia 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 używać wersji 2. Więcej informacji znajdziesz w artykule Zabezpieczanie zapytań dotyczących grup kolekcji.

Limity reguł zabezpieczeń

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

Limit Szczegóły
Maksymalna liczba wywołań exists(), get() i getAfter() na żądanie
  • 10 w przypadku żądań dotyczących pojedynczego dokumentu i zapytań.

  • 20 w przypadku odczytów z wielu dokumentów, transakcji i zapisów zbiorczych. Poprzedni limit 10 operacji obowiązuje również w przypadku każdej operacji.

    Załóżmy na przykład, że tworzysz żądanie zapisu wsadowego z 3 operacjami zapisu, a Twoje reguły zabezpieczeń używają 2 wywołań dostępu do dokumentu, aby zweryfikować każdy zapis. W tym przypadku każde zapisanie wykorzystuje 2 z 10 wywołań dostępu, a żądanie zapisu wsadowego wykorzystuje 6 z 20 wywołań dostępu.

Przekroczenie któregokolwiek z tych limitów spowoduje błąd dotyczący braku uprawnień.

Niektóre wywołania dostępu do dokumentów mogą być buforowane, a buforowane wywołania nie są wliczane do limitów.
Maksymalna głębokość zagnieżdżenia instrukcji match 10
Maksymalna długość ścieżki w segmentach ścieżki dozwolona w zbiorze zagnieżdżonych instrukcji match 100
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolonych w zagnieżdżonych instrukcjach 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 w ramach jednego żądania 1000
Maksymalny rozmiar zestawu reguł Zestawy reguł muszą spełniać 2 limity rozmiaru:
  • limit 256 KB na rozmiar źródła tekstowego zestawu reguł opublikowanego w Firebase konsoli lub w interfejsie CLI za pomocą polecenia firebase deploy.
  • limit 250 KB na rozmiar skompilowanego zestawu reguł, który powstaje, gdy Firebase przetwarza źródło i aktywuje je na backendzie.

Cloud Storage

Podstawowa struktura

Firebase Security Rules w Cloud Firestore i Cloud Storage używa tej 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ł warto znać te kluczowe pojęcia:

  • Żądanie: metoda lub metody wywoływane w instrukcji allow. To metody, które możesz uruchamiać. Standardowe metody to: get, list, create, update i delete. Metody wygody read i write umożliwiają szeroki dostęp do odczytu i zapisu w określonej bazie danych lub ścieżce do pamięci.
  • Ścieżka: lokalizacja bazy danych lub pamięci masowej przedstawiona jako ścieżka URI.
  • Reguła: instrukcja allow, która zawiera warunek zezwalający na żądanie, jeśli jego wartość to prawda.

Pasujące ścieżki

Cloud Storage Security Rules match ścieżki plików używane 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 także mogą być zagnieżdżone. Jeśli żadna reguła dopasowania nie zezwala na metodę żądania lub warunek ma wartość false, żądanie jest odrzucane.

Dopasowania ścisłe

// 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 dzikich kart

Reguły mogą też służyć do match wzorca z użyciem symboli wieloznacznych. Symbol wieloznaczny to nazwana zmienna, która reprezentuje pojedynczy ciąg znaków, np. profilePhoto.png, lub wiele segmentów ścieżki, np. images/profilePhoto.png.

Symbol wieloznaczny tworzy się, dodając nawiasy klamrowe wokół jego nazwy, np. {string}. Wielosegmentowy symbol wieloznaczny można zadeklarować, dodając znak =** 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 kilka reguł, wynikiem jest OR wyników wszystkich ocen reguł. Oznacza to, że jeśli jakakolwiek reguła w pliku pasuje do wartości true, wynikiem jest true.

W regułach plik „images/profilePhoto.png” można odczytać, jeśli wartość condition lub other_condition jest prawdziwa, natomiast plik „images/users/user:12345/profilePhoto.png” podlega tylko wynikowi other_condition.

Do zmiennej wieloznacznej można się odwoływać w ramach autoryzacji match provide filename 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.

Prośba o ocenę

Przesyłanie, pobieranie, zmiany metadanych i usuwanie są oceniane na podstawie request wysyłanych do Cloud Storage. Zmienna request zawiera ścieżkę, w której wykonywane jest żądanie, czas jego otrzymania oraz nową wartość resource, jeśli żądanie jest zapisem. Obejmuje to też nagłówki HTTP i stan uwierzytelniania.

Obiekt request zawiera też niepowtarzalny identyfikator użytkownika i ładunek Firebase Authentication w obiekcie request.auth, co zostanie dokładniej wyjaśnione w sekcji Uwierzytelnianie w dokumentacji.

Pełna lista właściwości obiektu request znajduje się poniżej:

Właściwość Typ Opis
auth map<string, string> Gdy użytkownik jest zalogowany, udostępnia uid, unikalny identyfikator użytkownika, i token, mapę deklaracji JWT Firebase Authentication. W przeciwnym razie będzie to null.
params map<string, string> Mapa zawierająca parametry zapytania żądania.
path ścieżka path reprezentujący ścieżkę, w której wykonywane jest żądanie.
resource map<string, string> Nowa wartość zasobu, która występuje tylko w przypadku żądań write.
time sygnatura czasowa Sygnatura czasowa reprezentująca czas serwera, w którym oceniane jest żądanie.

Ocena zasobów

Podczas oceny reguł możesz też oceniać metadane pliku przesyłanego, pobieranego, modyfikowanego lub usuwanego. Umożliwia to tworzenie złożonych i zaawansowanych reguł, które pozwalają na przykład zezwalać na przesyłanie tylko plików o określonych typach treści lub usuwać tylko pliki o określonym rozmiarze.

Firebase Security Rules dla Cloud Storage udostępnia metadane pliku w resourceobiekcie, który zawiera pary klucz/wartość metadanych wyświetlanych w obiekcie Cloud Storage. Te właściwości można sprawdzić w przypadku żądań 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ę w ścieżce żądania, możesz też używać obiektu request.resource, który zawiera podzbiór metadanych pliku, które mają zostać zapisane, jeśli zapis jest dozwolony. Możesz użyć tych 2 wartości, aby zapewnić integralność danych lub wymusić ograniczenia aplikacji, takie jak typ lub rozmiar pliku.

Pełna lista właściwości obiektu resource jest dostępna tutaj:

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.
metageneration int Google Cloud StorageGenerowanie metadanych obiektu tego obiektu.
size int Rozmiar obiektu w bajtach.
timeCreated sygnatura czasowa Sygnatura czasowa reprezentują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 Hash CRC32C obiektu.
etag ciąg znaków Tag 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 map<string, string> 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.

Limity reguł zabezpieczeń

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

Limit Szczegóły
Maksymalna liczba wywołań firestore.exists() i firestore.get() na żądanie

2 w przypadku żądań dotyczących pojedynczego dokumentu i zapytań.

Przekroczenie tego limitu spowoduje wyświetlenie błędu dotyczącego braku uprawnień.

Wywołania dostępu do tych samych dokumentów mogą być buforowane, a buforowane wywołania nie są wliczane do limitów.

Pełny przykład

Podsumowując, możesz utworzyć pełny przykład reguł dla rozwiązania do przechowywania obrazów:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // 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) Filename (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow read;
       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 Firebase Security Rules to wyrażenia podobne do JavaScriptu zawarte w dokumencie JSON.

Używają one tej 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. Odpowiada to strukturze JSON bazy danych.
  • Żądanie: są to metody, których reguła używa do przyznawania dostępu. Reguły read i write przyznają szerokie uprawnienia do odczytu i zapisu, a reguły validate działają jako dodatkowa weryfikacja, która przyznaje dostęp na podstawie danych przychodzących lub istniejących.
  • Warunek: warunek, który zezwala na żądanie, jeśli jego wartość to „prawda”.

Jak reguły są stosowane do ścieżek

W przypadku Realtime Database i Rules zmiany są stosowane 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 niższego poziomu nie mogą przyznawać dostępu do ścieżki nadrzędnej. Jeśli dostęp został już przyznany do jednej ze ścieżek nadrzędnych, nie można go zawęzić ani cofnąć w przypadku ścieżki znajdującej się głębiej w strukturze bazy danych.

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 odczytywanie elementu /bar/, gdy element /foo/ zawiera element podrzędny baz o wartości true. Reguła ".read": false w sekcji /foo/bar/ nie ma tu żadnego wpływu, ponieważ dostępu nie można cofnąć za pomocą ścieżki podrzędnej.

Choć może się to nie wydawać intuicyjne, jest to ważna część języka reguł, która 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 .validate reguły nie są kaskadowe. Aby zezwolić na zapis, na wszystkich poziomach hierarchii muszą być spełnione wszystkie reguły weryfikacji.

Dodatkowo, ponieważ reguły nie mają zastosowania do ścieżki nadrzędnej, operacje odczytu i zapisu kończą 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 całkowicie się nie powiedzie. Rozważ taką strukturę:

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

Jeśli nie wiesz, że reguły są oceniane niepodzielnie, może Ci się wydawać, że pobranie ścieżki /records/ zwróci rec1, ale nie rec2. Rzeczywisty wynik to jednak błąd:

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 klipów z 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
}];
Swift
Uwaga: ta usługa Firebase nie jest dostępna w przypadku klipów z 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

Ponieważ operacja odczytu w /records/ jest niepodzielna i nie ma reguły odczytu, która przyznaje dostęp do wszystkich danych w /records/, zostanie zgłoszony błąd PERMISSION_DENIED. Jeśli ocenimy tę regułę w symulatorze zabezpieczeń w naszej Firebasekonsoli, 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/. Zwróć jednak uwagę, że reguła dla ścieżki rec1 nigdy nie została oceniona, ponieważ nie znajdowała się w ścieżce, o którą prosiliśmy. Aby pobrać 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 klipów z aplikacji. 
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 przypadku klipów z 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ługują $locationzmienną do dopasowywania segmentów ścieżki. Użyj prefiksu $ 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żesz też używać symbolu $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 }
      }
    }
  }