Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Jak działają reguły bezpieczeństwa

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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 (kim jest użytkownik) i autoryzację (co użytkownik może zrobić).

Reguły zabezpieczeń Firebase usuwają warstwę środkową (serwerową) i umożliwiają określenie 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 stosowaniu reguł do żądań przychodzących.

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

Cloud Firestore

Podstawowa struktura

Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage wykorzystują 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óre pozwalasz. Standardowe metody to: get , list , create , update i delete . Wygodne metody read i write umożliwiają szeroki dostęp do odczytu i zapisu na 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 jego wartość jest prawdziwa.

Zasady bezpieczeństwa wersja 2

Od maja 2019 r. dostępna jest już wersja 2 reguł zabezpieczeń Firebase. Wersja 2 reguł zmienia zachowanie rekurencyjnych symboli wieloznacznych {name=**} . Musisz użyć wersji 2, jeśli planujesz używać kwerend grup kolekcji . Musisz wyrazić zgodę na wersję 2, rules_version = '2'; pierwszy wiersz w twoich zasadach bezpieczeństwa:

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

Pasujące ścieżki

Wszystkie stwierdzenia zgodności powinny wskazywać na dokumenty, a nie kolekcje. Wyrażenie match może wskazywać na określony dokument, jak w match /cities/SF lub używać symboli wieloznacznych, aby wskazać dowolny dokument w określonej ścieżce, jak w match /cities/{city} .

W powyższym przykładzie instrukcja match używa składni symboli wieloznacznych {city} . Oznacza to, że reguła dotyczy każdego dokumentu w kolekcji cities , np. /cities/SF lub /cities/NYC . Gdy wyrażenia allow w instrukcji dopasowania zostaną ocenione, zmienna city zostanie rozpoznana jako nazwa dokumentu miasta, na przykład SF lub NYC .

Pasujące kolekcje podrzędne

Dane w Cloud Firestore są zorganizowane w kolekcje dokumentów, a każdy dokument może rozszerzać hierarchię poprzez kolekcje podrzędne. Ważne jest, aby zrozumieć, w jaki sposób reguły zabezpieczeń współdziałają z danymi hierarchicznymi.

Rozważ sytuację, w której każdy dokument w kolekcji cities zawiera podzbiór landmarks . Reguły bezpieczeństwa mają zastosowanie tylko w dopasowanej ścieżce, więc kontrole dostępu zdefiniowane w kolekcji cities nie mają zastosowania do podkolekcji landmarks . Zamiast tego napisz wyraźne reguły, aby kontrolować 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 do ścieżki zewnętrznej instrukcji match . Poniższe 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 były stosowane 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 rekursywnej 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 byłaby 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ęcej 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 , podczas gdy match /cities/{document=**} dopasowuje oba dokumenty w zbiór cities i podkolekcje.

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

Wersja 2

W wersji 2 reguł zabezpieczeń rekurencyjne symbole wieloznaczne pasują do zera lub większej liczby elementów ścieżki. match/cities/{city}/{document=**} dopasowuje dokumenty w dowolnych podkolekcjach oraz dokumenty w kolekcji cities .

Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2'; u góry Twoich zasad 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 w 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 kwerend grup kolekcji , musisz użyć wersji 2, zobacz zabezpieczanie kwerend grup kolekcji .

Pokrywające się stwierdzenia dotyczące dopasowania

Dokument może być zgodny z więcej niż jednym stwierdzeniem 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 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, zwróć uwagę na następujące ograniczenia:

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

    Na przykład wyobraź sobie, że tworzysz grupowe żądanie zapisu z 3 operacjami zapisu, a Twoje reguły zabezpieczeń używają 2 wywołań dostępu do dokumentów do sprawdzania poprawności każdego zapisu. W tym przypadku każdy zapis wykorzystuje 2 z 10 wywołań dostępu, a grupowe żądanie zapisu wykorzystuje 6 z 20 wywołań dostępu.

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 wiązań let zmiennej 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ą być zgodne z dwoma ograniczeniami rozmiaru:
  • ograniczenie do 256 KB rozmiaru źródła tekstu zestawu reguł opublikowanego z konsoli Firebase lub z interfejsu wiersza polecenia przy użyciu narzędzia firebase deploy .
  • limit 250 KB rozmiaru skompilowanego zestawu reguł, który powstaje, gdy Firebase przetwarza źródło i uaktywnia je na zapleczu.

Magazyn w chmurze

Podstawowa struktura

Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage wykorzystują 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óre pozwalasz. Standardowe metody to: get , list , create , update i delete . Wygodne metody read i write umożliwiają szeroki dostęp do odczytu i zapisu na 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 jego wartość jest prawdziwa.

Pasujące ścieżki

Reguły bezpieczeństwa Cloud Storage są match ze ścieżkami plików używanymi do uzyskiwania dostępu do plików w Cloud Storage. Reguły mogą match ścisłym ścieżkom lub ścieżkom 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 jest odrzucane.

Dopasowania dokładne

// 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 wieloznaczne

Reguły można również wykorzystać do match wzorca za pomocą symboli wieloznacznych. Symbol wieloznaczny to nazwana zmienna, która reprezentuje pojedynczy ciąg, taki jak profilePhoto.png , lub 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} . Wieloznaczny symbol wielosegmentowy 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 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 nazwy pliku lub ścieżki uwierzytelnienia match :

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

Reguły zabezpieczeń Cloud Storage nie działają kaskadowo, a reguły są oceniane tylko wtedy, gdy ścieżka żądania jest zgodna ze ścieżką z określonymi regułami.

Poproś o ocenę

Przesyłanie, pobieranie, zmiany metadanych i usuwanie są oceniane na podstawie request wysłanego do Cloud Storage. Zmienna request zawiera ścieżkę pliku, w którym żądanie jest wykonywane, czas odebrania żą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 , który zostanie wyjaśniony w dalszej części dokumentu w sekcji Uwierzytelnianie .

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

Nieruchomość Rodzaj Opis
auth mapa<ciąg, ciąg> Gdy użytkownik jest zalogowany, udostępnia uid , unikalny identyfikator użytkownika i token , mapę oświadczeń JWT uwierzytelniania Firebase. W przeciwnym razie będzie to 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 żądanie jest oceniane.

Ocena zasobów

Podczas oceny reguł możesz również chcieć ocenić metadane przesyłanego, pobieranego, modyfikowanego lub usuwanego pliku. Pozwala to na tworzenie złożonych i potężnych reguł, które pozwalają na przesyłanie tylko plików z określonymi typami treści lub usuwanie tylko plików większych niż określony rozmiar.

Reguły zabezpieczeń Firebase dla Cloud Storage udostępniają metadane plików w obiekcie resource , które zawierają pary klucz/wartość metadanych pojawiających się w obiekcie Cloud Storage. Te właściwości można sprawdzać w żądaniach read lub write , aby zapewnić integralność danych.

W przypadku żądań write (takich jak przesyłanie, aktualizacje metadanych i usuwanie), oprócz obiektu resource , który zawiera metadane pliku dla pliku, który aktualnie istnieje w ścieżce żądania, masz również możliwość korzystania z 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 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ść Rodzaj 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 tego obiektu.
metageneration int Metageneracja obiektu Google Cloud Storage tego obiektu.
size int 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 Skrót MD5 obiektu.
crc32c strunowy Skrót crc32c obiektu.
etag strunowy etag skojarzony z tym obiektem.
contentDisposition strunowy Dyspozycja zawartości skojarzona 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 skojarzony 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 .

Limity reguł bezpieczeństwa

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

Limit Detale
Maksymalna liczba wywołań 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 zabezpieczeń Firebase składają się z wyrażeń podobnych do 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>>
    }
  }
}

W regule są trzy podstawowe elementy:

  • Ścieżka: lokalizacja bazy danych. To odzwierciedla strukturę JSON bazy danych.
  • Żądanie: są to metody, których używa reguła do przyznania dostępu. Reguły read i write zapewniają szeroki dostęp do odczytu i zapisu, podczas gdy reguły validate działają jako wtórna weryfikacja w celu przyznania dostępu na podstawie danych przychodzących lub istniejących.
  • Warunek: warunek, który zezwala na żądanie, jeśli jego ocena ma wartość prawda.

Jak zasady odnoszą się do ścieżek

W Bazie danych czasu rzeczywistego reguły 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 głębszym węźle nie mogą udzielić dostępu do ścieżki nadrzędnej. Nie można doprecyzować ani odwołać dostępu w głębszej ścieżce w strukturze bazy danych, jeśli przyznano go już 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 bezpieczeństwa pozwala na odczytanie /bar/ z każdego miejsca, w którym /foo/ zawiera potomny baz z wartością true . ".read": false reguła w /foo/bar/ nie ma tu żadnego efektu, ponieważ dostęp nie może zostać odwołany przez ścieżkę podrzędną.

Choć może nie wydawać się to od razu intuicyjne, jest to potężna część języka reguł i pozwala na implementację 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 działają kaskadowo. Aby zapis był dozwolony, wszystkie reguły walidacji 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 udziela dostępu. 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ż tę strukturę:

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

Bez zrozumienia, że ​​reguły są oceniane niepodzielnie, 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 miejscu docelowym klipu 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 miejscu docelowym klipu 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
  });
});
RESZTA
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 przyznałaby dostęp do wszystkich danych w /records/ , spowoduje to zgłoszenie 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ę 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 miejscu docelowym klipu 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 miejscu docelowym klipu 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
  }
});
RESZTA
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 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 również 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 }
      }
    }
  }