Save the date - Google I/O returns May 18-20. Register to get the most out of the digital experience: Build your schedule, reserve space, participate in Q&As, earn Google Developer profile badges, and more. Register now
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Język reguł bezpieczeństwa

Reguły zabezpieczeń Firebase wykorzystują elastyczne, zaawansowane, niestandardowe języki, które obsługują szeroki zakres złożoności i szczegółowości. Możesz ustawić reguły tak szczegółowe lub ogólne, jak ma to sens dla Twojej aplikacji. Reguły bazy danych czasu rzeczywistego używają składni, która wygląda jak JavaScript w strukturze JSON. Reguły Cloud Firestore i Cloud Storage używają języka opartego na Common Expression Language (CEL) , który opiera się na CEL z match i allow instrukcje obsługujące warunkowo przyznany dostęp.

Ponieważ są to języki niestandardowe, istnieje jednak krzywa uczenia się. Skorzystaj z tego przewodnika, aby lepiej zrozumieć język Reguł i zagłębić się w bardziej złożone zasady.

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

Podstawowa struktura

Cloud Firestore

Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:

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

Podczas tworzenia reguł należy zrozumieć następujące kluczowe pojęcia:

  • Żą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 . Do read i write metody wygoda umożliwić szeroki dostęp do odczytu i zapisu na określonej ścieżce bazy danych lub pamięci masowej.
  • Ścieżka: baza danych lub lokalizacja magazynu reprezentowana jako ścieżka identyfikatora URI.
  • Reguła: instrukcja allow , która zawiera warunek, który zezwala na żądanie, jeśli uzyska wartość true.

Każda z tych koncepcji została szczegółowo opisana poniżej.

Magazyn w chmurze

Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:

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

Podczas tworzenia reguł należy zrozumieć następujące kluczowe pojęcia:

  • Żą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 . Do read i write metody wygoda umożliwić szeroki dostęp do odczytu i zapisu na określonej ścieżce bazy danych lub pamięci masowej.
  • Ścieżka: baza danych lub lokalizacja magazynu reprezentowana jako ścieżka identyfikatora URI.
  • Reguła: instrukcja allow , która zawiera warunek, który zezwala na żądanie, jeśli uzyska wartość true.

Każda z tych koncepcji została szczegółowo opisana poniżej.

Baza danych czasu rzeczywistego

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

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, podczas gdy reguły validate działają jako wtórna weryfikacja w celu przyznania dostępu na podstawie przychodzących lub istniejących danych.
  • Warunek: warunek, który zezwala na żądanie, jeśli zostanie ocenione jako prawda.

Konstrukcje reguł

Cloud Firestore

Podstawowe elementy reguły w Cloud Firestore i Cloud Storage są następujące:

  • Deklaracja service : deklaruje produkt Firebase, którego dotyczą reguły.
  • Blok match : definiuje ścieżkę w bazie danych lub zasobniku pamięci, do którego mają zastosowanie reguły.
  • Instrukcja allow : zapewnia warunki przyznawania dostępu, zróżnicowane według metod. Obsługiwane metody obejmują: get , list , create , update , delete oraz wygodne metody read i write .
  • Opcjonalne deklaracje function : zapewniają możliwość łączenia i zawijania warunków do użycia w wielu regułach.

service zawiera jeden lub więcej bloków match z instrukcjami allow , które zapewniają warunki przyznawania dostępu do żądań. Zmienne request i resource są dostępne do użycia w warunkach reguły. Język reguł zabezpieczeń Firebase obsługuje również deklaracje function .

Wersja składni

Instrukcja syntax wskazuje wersję języka reguł Firebase użytą do napisania źródła. Najnowsza wersja języka to v2 .

rules_version = '2';
service cloud.firestore {
...
}

Jeśli nie rules_version instrukcji rules_version , Twoje reguły zostaną ocenione przy użyciu silnika v1 .

Usługa

Deklaracja service określa, do którego produktu lub usługi Firebase mają zastosowanie Twoje reguły. Możesz dołączyć tylko jedną deklarację service na plik źródłowy.

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

Magazyn w chmurze

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

Jeśli definiujesz reguły zarówno dla Cloud Firestore, jak i Cloud Storage za pomocą interfejsu wiersza polecenia Firebase, musisz przechowywać je w osobnych plikach.

Mecz

Blok match deklaruje wzorzec path , który jest dopasowywany do ścieżki dla żądanej operacji (przychodząca ścieżka request.path ). Treść match musi mieć jeden lub więcej zagnieżdżonych bloków match , instrukcji allow lub deklaracji function . Ścieżka w zagnieżdżonych blokach match jest względna w stosunku do ścieżki w nadrzędnym bloku match .

Wzorzec path to nazwa podobna do katalogu, która może zawierać zmienne lub symbole wieloznaczne. Wzorzec path umożliwia dopasowywanie segmentów jednościeżkowych i segmentów wielościeżkowych. Wszelkie zmienne powiązane w path są widoczne w zakresie match lub w dowolnym zagnieżdżonym zakresie, w którym zadeklarowano path .

Dopasowania do wzorca path mogą być częściowe lub całkowite:

  • Częściowe dopasowania: wzorzec path jest przedrostkiem request.path z request.path .
  • Kompletne dopasowania: wzorzec path pasuje do całej path request.path .

Po całkowitym dopasowaniu zasady w bloku są oceniane. Po wykonaniu częściowego dopasowania zagnieżdżone reguły match są testowane w celu sprawdzenia, czy jakakolwiek zagnieżdżona path zakończy dopasowanie.

Reguły w każdym pełnym match są oceniane w celu określenia, czy zezwolić na żądanie. Jeśli jakakolwiek reguła dopasowania przyznaje dostęp, żądanie jest dozwolone. Jeśli żadna reguła dopasowania nie przyznaje dostępu, żądanie jest odrzucane.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

Jak pokazuje powyższy przykład, deklaracje path obsługują następujące zmienne:

  • Jednosegmentowy symbol wieloznaczny: zmienna wieloznaczna jest deklarowana w ścieżce poprzez umieszczenie zmiennej w nawiasach klamrowych: {variable} . Ta zmienna jest dostępna w instrukcji match jako string .
  • Rekursywny symbol wieloznaczny: rekursywny lub wielosegmentowy symbol wieloznaczny dopasowuje wiele segmentów ścieżki na lub poniżej ścieżki. Ten symbol wieloznaczny pasuje do wszystkich ścieżek poniżej ustawionej lokalizacji. Możesz to zadeklarować, dodając ciąg =** na końcu zmiennej segmentu: {variable=**} . Ta zmienna jest dostępna w instrukcji match jako obiekt path .

Dopuszczać

Blok match zawiera co najmniej jedną instrukcję allow . To są twoje rzeczywiste zasady. Możesz zastosować reguły allow na jedną lub więcej metod. Warunki w instrukcji allow muszą mieć wartość true, aby Cloud Firestore lub Cloud Storage spełniały wszelkie przychodzące żądania. Możesz także napisać instrukcje allow bez warunków, na przykład allow read . Jeśli jednak instrukcja allow nie zawiera warunku, zawsze zezwala na żądanie tej metody.

Jeśli którakolwiek z reguł allow dla metody jest spełniona, żądanie jest dozwolone. Ponadto, jeśli szersza reguła przyznaje dostęp, reguły przyznają dostęp i ignorują bardziej szczegółowe reguły, które mogą ograniczać dostęp.

Rozważmy następujący przykład, w którym każdy użytkownik może odczytać lub usunąć dowolne ze swoich plików. Bardziej szczegółowa reguła zezwala na zapis tylko wtedy, gdy użytkownik żądający zapisu jest właścicielem pliku, a plik jest plikiem PNG. Użytkownik może usunąć dowolne pliki ze ścieżki podrzędnej - nawet jeśli nie są to pliki PNG - ponieważ pozwala na to wcześniejsza reguła.

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

metoda

Każda instrukcja allow zawiera metodę, która przyznaje dostęp do żądań przychodzących za pomocą tej samej metody.

metoda Typ prośby
Wygodne metody
read Żądanie odczytu dowolnego typu
write Każdy rodzaj żądania zapisu
Metody standardowe
get Przeczytaj wnioski o pojedyncze dokumenty lub pliki
list Czytaj żądania zapytań i kolekcji
create Napisz nowe dokumenty lub pliki
update Napisz do istniejących dokumentów lub plików
delete Usunąć dane

Nie można nakładać metod odczytu w tym samym bloku match ani sprzecznych metod zapisu w tej samej deklaracji path .

Na przykład zawiodą następujące reguły:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

Funkcjonować

Ponieważ reguły bezpieczeństwa stają się bardziej złożone, możesz chcieć zawinąć zestawy warunków w funkcje, których możesz ponownie użyć w całym zestawie reguł. Reguły bezpieczeństwa obsługują funkcje niestandardowe. Składnia funkcji niestandardowych jest trochę podobna do JavaScript, ale funkcje reguł bezpieczeństwa są napisane w języku specyficznym dla domeny, który ma kilka ważnych ograniczeń:

  • Funkcje mogą zawierać tylko jedną instrukcję return . Nie mogą zawierać żadnej dodatkowej logiki. Na przykład nie mogą wykonywać pętli ani wywoływać usług zewnętrznych.
  • Funkcje mogą automatycznie uzyskiwać dostęp do funkcji i zmiennych z zakresu, w którym zostały zdefiniowane. Na przykład funkcja zdefiniowana w zakresie service cloud.firestore ma dostęp do zmiennej resource i wbudowanych funkcji, takich jak get() i exists() .
  • Funkcje mogą wywoływać inne funkcje, ale nie mogą się powtarzać. Całkowita głębokość stosu wywołań jest ograniczona do 20.
  • W wersji v2 reguł funkcje mogą definiować zmienne za pomocą słowa kluczowego let . Funkcje mogą mieć maksymalnie 10 powiązań let, ale muszą kończyć się instrukcją return.

Funkcja jest definiowana za pomocą słowa kluczowego function i przyjmuje zero lub więcej argumentów. Na przykład możesz chcieć połączyć dwa typy warunków użytych w powyższych przykładach w jedną funkcję:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

Oto przykład pokazujący argumenty funkcji i przypisania let. Niech instrukcje przypisania muszą być oddzielone średnikami.

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

Zwróć uwagę, jak przypisanie isAdmin wymusza przeszukiwanie kolekcji admins. Dla leniwej oceny bez konieczności niepotrzebnych wyszukiwań, skorzystaj ze zwarciowego charakteru && (AND) i || (LUB) porównania, aby wywołać drugą funkcję tylko wtedy, gdy isAuthor ma wartość prawda (dla porównań && ) lub fałsz (dla porównań || ).

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

Używanie funkcji w regułach bezpieczeństwa sprawia, że ​​są one łatwiejsze do utrzymania w miarę wzrostu złożoności reguł.

Magazyn w chmurze

Podstawowe elementy reguły w Cloud Firestore i Cloud Storage są następujące:

  • Deklaracja service : deklaruje produkt Firebase, którego dotyczą reguły.
  • Blok match : definiuje ścieżkę w bazie danych lub zasobniku pamięci, do którego mają zastosowanie reguły.
  • Instrukcja allow : zapewnia warunki przyznawania dostępu, zróżnicowane według metod. Obsługiwane metody obejmują: get , list , create , update , delete oraz wygodne metody read i write .
  • Opcjonalne deklaracje function : zapewniają możliwość łączenia i zawijania warunków do użycia w wielu regułach.

service zawiera jeden lub więcej bloków match z instrukcjami allow , które zapewniają warunki przyznawania dostępu do żądań. Zmienne request i resource są dostępne do użycia w warunkach reguły. Język reguł zabezpieczeń Firebase obsługuje również deklaracje function .

Wersja składni

Instrukcja syntax wskazuje wersję języka reguł Firebase użytą do napisania źródła. Najnowsza wersja języka to v2 .

rules_version = '2';
service cloud.firestore {
...
}

Jeśli nie rules_version instrukcji rules_version , Twoje reguły zostaną ocenione przy użyciu silnika v1 .

Usługa

Deklaracja service określa, do którego produktu lub usługi Firebase mają zastosowanie Twoje reguły. Możesz dołączyć tylko jedną deklarację service na plik źródłowy.

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

Magazyn w chmurze

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

Jeśli definiujesz reguły zarówno dla Cloud Firestore, jak i Cloud Storage za pomocą interfejsu wiersza polecenia Firebase, musisz przechowywać je w osobnych plikach.

Mecz

Blok match deklaruje wzorzec path , który jest dopasowywany do ścieżki dla żądanej operacji (przychodząca ścieżka request.path ). Treść match musi mieć jeden lub więcej zagnieżdżonych bloków match , instrukcji allow lub deklaracji function . Ścieżka w zagnieżdżonych blokach match jest względna w stosunku do ścieżki w nadrzędnym bloku match .

Wzorzec path to nazwa podobna do katalogu, która może zawierać zmienne lub symbole wieloznaczne. Wzorzec path umożliwia dopasowywanie segmentów jednościeżkowych i segmentów wielościeżkowych. Wszelkie zmienne powiązane w path są widoczne w zakresie match lub w dowolnym zagnieżdżonym zakresie, w którym zadeklarowano path .

Dopasowania do wzorca path mogą być częściowe lub całkowite:

  • Częściowe dopasowania: wzorzec path jest przedrostkiem request.path z request.path .
  • Kompletne dopasowania: wzorzec path pasuje do całej path request.path .

Po całkowitym dopasowaniu zasady w bloku są oceniane. Po wykonaniu częściowego dopasowania zagnieżdżone reguły match są testowane w celu sprawdzenia, czy jakakolwiek zagnieżdżona path zakończy dopasowanie.

Reguły w każdym pełnym match są oceniane w celu określenia, czy zezwolić na żądanie. Jeśli jakakolwiek reguła dopasowania przyznaje dostęp, żądanie jest dozwolone. Jeśli żadna reguła dopasowania nie przyznaje dostępu, żądanie jest odrzucane.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

Jak pokazuje powyższy przykład, deklaracje path obsługują następujące zmienne:

  • Jednosegmentowy symbol wieloznaczny: zmienna wieloznaczna jest deklarowana w ścieżce poprzez umieszczenie zmiennej w nawiasach klamrowych: {variable} . Ta zmienna jest dostępna w instrukcji match jako string .
  • Rekursywny symbol wieloznaczny: rekursywny lub wielosegmentowy symbol wieloznaczny dopasowuje wiele segmentów ścieżki na lub poniżej ścieżki. Ten symbol wieloznaczny pasuje do wszystkich ścieżek poniżej ustawionej lokalizacji. Możesz to zadeklarować, dodając ciąg =** na końcu zmiennej segmentu: {variable=**} . Ta zmienna jest dostępna w instrukcji match jako obiekt path .

Dopuszczać

Blok match zawiera co najmniej jedną instrukcję allow . To są twoje rzeczywiste zasady. Możesz zastosować reguły allow na jedną lub więcej metod. Warunki w instrukcji allow muszą mieć wartość true, aby Cloud Firestore lub Cloud Storage spełniały wszelkie przychodzące żądania. Możesz także napisać instrukcje allow bez warunków, na przykład allow read . Jeśli jednak instrukcja allow nie zawiera warunku, zawsze zezwala na żądanie tej metody.

Jeśli którakolwiek z reguł allow dla metody jest spełniona, żądanie jest dozwolone. Ponadto, jeśli szersza reguła przyznaje dostęp, reguły przyznają dostęp i ignorują bardziej szczegółowe reguły, które mogą ograniczać dostęp.

Rozważmy następujący przykład, w którym każdy użytkownik może odczytać lub usunąć dowolne ze swoich plików. Bardziej szczegółowa reguła zezwala na zapis tylko wtedy, gdy użytkownik żądający zapisu jest właścicielem pliku, a plik jest plikiem PNG. Użytkownik może usunąć dowolne pliki ze ścieżki podrzędnej - nawet jeśli nie są to pliki PNG - ponieważ pozwala na to wcześniejsza reguła.

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

metoda

Każda instrukcja allow zawiera metodę, która przyznaje dostęp do żądań przychodzących za pomocą tej samej metody.

metoda Typ prośby
Wygodne metody
read Żądanie odczytu dowolnego typu
write Każdy rodzaj żądania zapisu
Metody standardowe
get Przeczytaj wnioski o pojedyncze dokumenty lub pliki
list Czytaj żądania zapytań i kolekcji
create Napisz nowe dokumenty lub pliki
update Napisz do istniejących dokumentów lub plików
delete Usunąć dane

Nie można nakładać metod odczytu w tym samym bloku match ani sprzecznych metod zapisu w tej samej deklaracji path .

Na przykład zawiodą następujące reguły:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

Funkcjonować

Ponieważ reguły bezpieczeństwa stają się bardziej złożone, możesz chcieć zawinąć zestawy warunków w funkcje, których możesz ponownie użyć w całym zestawie reguł. Reguły bezpieczeństwa obsługują funkcje niestandardowe. Składnia funkcji niestandardowych jest trochę podobna do JavaScript, ale funkcje reguł bezpieczeństwa są napisane w języku specyficznym dla domeny, który ma kilka ważnych ograniczeń:

  • Funkcje mogą zawierać tylko jedną instrukcję return . Nie mogą zawierać żadnej dodatkowej logiki. Na przykład nie mogą wykonywać pętli ani wywoływać usług zewnętrznych.
  • Funkcje mogą automatycznie uzyskiwać dostęp do funkcji i zmiennych z zakresu, w którym zostały zdefiniowane. Na przykład funkcja zdefiniowana w zakresie service cloud.firestore ma dostęp do zmiennej resource i wbudowanych funkcji, takich jak get() i exists() .
  • Funkcje mogą wywoływać inne funkcje, ale nie mogą się powtarzać. Całkowita głębokość stosu wywołań jest ograniczona do 20.
  • W wersji v2 reguł funkcje mogą definiować zmienne za pomocą słowa kluczowego let . Funkcje mogą mieć maksymalnie 10 powiązań let, ale muszą kończyć się instrukcją return.

Funkcja jest definiowana za pomocą słowa kluczowego function i przyjmuje zero lub więcej argumentów. Na przykład możesz chcieć połączyć dwa typy warunków użytych w powyższych przykładach w jedną funkcję:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

Oto przykład pokazujący argumenty funkcji i przypisania let. Niech instrukcje przypisania muszą być oddzielone średnikami.

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

Zwróć uwagę, jak przypisanie isAdmin wymusza przeszukiwanie kolekcji admins. Aby przeprowadzić leniwą ocenę bez konieczności niepotrzebnych wyszukiwań, skorzystaj ze zwarciowego charakteru && (AND) i || (LUB) porównania, aby wywołać drugą funkcję tylko wtedy, gdy isAuthor ma wartość prawda (dla porównań && ) lub fałsz (dla porównań || ).

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

Używanie funkcji w regułach bezpieczeństwa sprawia, że ​​są one łatwiejsze do utrzymania w miarę wzrostu złożoności reguł.

Baza danych czasu rzeczywistego

Jak wspomniano powyżej, Reguły bazy danych czasu rzeczywistego obejmują trzy podstawowe elementy: lokalizację bazy danych jako lustro struktury JSON bazy danych, typ żądania i warunek przyznania dostępu.

Lokalizacja bazy danych

Struktura reguł powinna odpowiadać strukturze danych przechowywanych w bazie danych. Na przykład w aplikacji do czatu z listą wiadomości możesz mieć takie dane:

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

Twoje zasady powinny odzwierciedlać tę strukturę. Na przykład:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

Jak pokazuje powyższy przykład, reguły bazy danych czasu rzeczywistego obsługują zmienną $location 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żesz również użyć $variable równolegle z nazwami stałych ś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 }
      }
    }
  }

metoda

W bazie danych czasu rzeczywistego istnieją trzy typy reguł. Dwa z tych typów reguł - read i write - mają zastosowanie do metody żądania przychodzącego. Typ reguły validate wymusza struktury danych i weryfikuje format i zawartość danych. Reguły uruchamiają reguły .validate po zweryfikowaniu, że reguła .write przyznaje dostęp.

Typy reguł
.czytać Opisuje, czy i kiedy dane mogą być odczytywane przez użytkowników.
.pisać Opisuje, czy i kiedy można zapisywać dane.
.uprawomocnić Określa, jak będzie wyglądać poprawnie sformatowana wartość, czy ma atrybuty potomne i typ danych.

Domyślnie, jeśli nie ma reguły, która na to zezwala, dostęp na ścieżce jest zabroniony.

Warunki zabudowy

Cloud Firestore

Warunek jest wyrażeniem logicznym, które określa, czy dana operacja powinna być dozwolona, ​​czy zabroniona. Zmienne request i resource zapewniają kontekst dla tych warunków.

Zmienna request

Zmienna request zawiera następujące pola i odpowiednie informacje:

request.auth

Token sieciowy JSON (JWT) zawierający dane uwierzytelniające z uwierzytelniania Firebase. token auth zawiera zestaw oświadczeń standardowych i wszelkich oświadczeń niestandardowych utworzonych za pomocą uwierzytelniania Firebase. Dowiedz się więcej o regułach zabezpieczeń i uwierzytelnianiu Firebase .

request.method

request.method może być dowolną metodą standardową lub niestandardową. Istnieją również wygodne metody read i write w celu uproszczenia reguł pisania, które mają zastosowanie odpowiednio do wszystkich standardowych metod tylko do odczytu lub tylko do zapisu.

request.params

Parametr request.params zawiera wszelkie dane niezwiązane konkretnie z request.resource które mogą być przydatne do oceny. W praktyce ta mapa powinna być pusta dla wszystkich metod standardowych i powinna zawierać dane niebędące zasobami dla metod niestandardowych. Usługi muszą uważać, aby nie zmieniać nazwy ani nie modyfikować typu żadnego z kluczy i wartości przedstawionych jako parametry.

request.path

request.path to ścieżka do resource docelowego. Ścieżka jest zależna od usługi. Segmenty ścieżki zawierające znaki inne niż bezpieczne adresy URL, takie jak / są zakodowane w postaci adresu URL.

Zmienna resource

resource to bieżąca wartość w usłudze reprezentowana jako mapa par klucz-wartość. Odwołanie się do resource w warunku spowoduje co najwyżej jeden odczyt wartości z usługi. To wyszukiwanie będzie wliczane do dowolnego przydziału związanego z usługą dla zasobu. W przypadku żądań get resource będzie się liczył tylko w przypadku odmowy przydziału.

Operatory i pierwszeństwo operatorów

Skorzystaj z poniższej tabeli jako odniesienia dla operatorów i ich pierwszeństwa w regułach dotyczących Cloud Firestore i Cloud Storage.

Biorąc pod uwagę dowolne wyrażenia a i b , pole f oraz indeks i .

Operator Opis Łączność
a[i] a() af Indeks, wywołanie, dostęp do pola z lewej na prawą
!a -a Jednoargumentowa negacja od prawej do lewej
a/ba%ba*b Operatory multiplikatywne z lewej na prawą
a+b ab Operatory addytywne z lewej na prawą
a>b a>=b a<b a<=b Operatorzy relacyjni z lewej na prawą
a in b , a is b Obecność na liście lub mapie, porównanie typów z lewej na prawą
a==ba!=b Operatory porównania z lewej na prawą
a && b Warunkowe i z lewej na prawą
a || b Warunkowe LUB z lewej na prawą
a ? true_value : false_value Wyrażenie trójskładnikowe z lewej na prawą

Magazyn w chmurze

Warunek jest wyrażeniem logicznym, które określa, czy dana operacja powinna być dozwolona, ​​czy zabroniona. Zmienne request i resource zapewniają kontekst dla tych warunków.

Zmienna request

Zmienna request zawiera następujące pola i odpowiednie informacje:

request.auth

Token sieciowy JSON (JWT) zawierający dane uwierzytelniające z uwierzytelniania Firebase. token auth zawiera zestaw oświadczeń standardowych i wszelkich oświadczeń niestandardowych utworzonych za pomocą uwierzytelniania Firebase. Dowiedz się więcej o regułach zabezpieczeń i uwierzytelnianiu Firebase .

request.method

request.method może być dowolną metodą standardową lub niestandardową. Istnieją również wygodne metody read i write w celu uproszczenia reguł pisania, które mają zastosowanie odpowiednio do wszystkich standardowych metod tylko do odczytu lub tylko do zapisu.

request.params

Parametr request.params zawiera wszelkie dane niezwiązane konkretnie z request.resource które mogą być przydatne do oceny. W praktyce ta mapa powinna być pusta dla wszystkich metod standardowych i powinna zawierać dane niebędące zasobami dla metod niestandardowych. Usługi muszą uważać, aby nie zmieniać nazwy ani nie modyfikować typu żadnego z kluczy i wartości przedstawionych jako parametry.

request.path

request.path jest ścieżką do resource docelowego. Ścieżka jest zależna od usługi. Segmenty ścieżki zawierające znaki inne niż bezpieczne adresy URL, takie jak / są zakodowane w postaci adresu URL.

Zmienna resource

resource to bieżąca wartość w usłudze reprezentowana jako mapa par klucz-wartość. Odwołanie się do resource w warunku spowoduje co najwyżej jeden odczyt wartości z usługi. To wyszukiwanie będzie wliczane do dowolnego przydziału związanego z usługą dla zasobu. W przypadku żądań get resource będzie się liczył tylko w przypadku odmowy przydziału.

Operatory i pierwszeństwo operatorów

Skorzystaj z poniższej tabeli jako odniesienia dla operatorów i ich pierwszeństwa w regułach dotyczących Cloud Firestore i Cloud Storage.

Biorąc pod uwagę dowolne wyrażenia a i b , pole f oraz indeks i .

Operator Opis Łączność
a[i] a() af Indeks, wezwanie, dostęp do pola z lewej na prawą
!a -a Jednoargumentowa negacja od prawej do lewej
a/ba%ba*b Operatory multiplikatywne z lewej na prawą
a+b ab Operatory addytywne z lewej na prawą
a>b a>=b a<b a<=b Operatorzy relacyjni z lewej na prawą
a in b , a is b Obecność na liście lub mapie, porównanie typów z lewej na prawą
a==ba!=b Operatory porównania z lewej na prawą
a && b Warunkowe AND z lewej na prawą
a || b Warunkowe LUB z lewej na prawą
a ? true_value : false_value Wyrażenie trójskładnikowe z lewej na prawą

Baza danych czasu rzeczywistego

Warunek jest wyrażeniem logicznym, które określa, czy dana operacja powinna być dozwolona, ​​czy zabroniona. Możesz zdefiniować te warunki w Regułach bazy danych czasu rzeczywistego w następujący sposób.

Predefiniowane zmienne

Istnieje wiele przydatnych, wstępnie zdefiniowanych zmiennych, do których można uzyskać dostęp w ramach definicji reguły. Oto krótkie podsumowanie każdego z nich:

Predefiniowane zmienne
teraz Bieżący czas w milisekundach od epoki Linuksa. Działa to szczególnie dobrze w przypadku walidacji sygnatur czasowych utworzonych za pomocą firebase.database.ServerValue.TIMESTAMP pakietu SDK.
korzeń RuleDataSnapshot reprezentująca ścieżkę główną w bazie danych Firebase, jaka istnieje przed próbą wykonania operacji.
nowe dane RuleDataSnapshot reprezentujący dane w takiej postaci, w jakiej istniałyby po próbie wykonania operacji. Obejmuje nowo zapisywane dane i istniejące dane.
dane RuleDataSnapshot reprezentujący dane w postaci, w jakiej istniały przed próbą wykonania operacji.
$ zmienne Ścieżka z symbolem wieloznacznym używana do reprezentowania identyfikatorów i dynamicznych kluczy podrzędnych.
auth Reprezentuje ładunek tokenu uwierzytelnionego użytkownika.

Te zmienne mogą być używane w dowolnym miejscu w regułach. Na przykład poniższe reguły bezpieczeństwa zapewniają, że dane zapisane w węźle /foo/ muszą być ciągiem krótszym niż 100 znaków:

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

Reguły oparte na danych

Wszelkie dane w Twojej bazie danych mogą zostać użyte w Twoich regułach. Używając predefiniowanych zmiennych root , data i newData , można uzyskać dostęp do dowolnej ścieżki, jaka istniałaby przed lub po zdarzeniu write.

Rozważmy ten przykład, który zezwala na operacje zapisu, o ile wartość węzła /allow_writes/ jest true , węzeł nadrzędny nie ma readOnly flagi readOnly , aw nowo zapisywanych danych znajduje się dziecko o nazwie foo :

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Reguły oparte na zapytaniach

Chociaż nie możesz używać reguł jako filtrów, możesz ograniczyć dostęp do podzbiorów danych, używając parametrów zapytania w regułach. Użyj query. wyrażenia w regułach, aby przyznać dostęp do odczytu lub zapisu na podstawie parametrów zapytania.

Na przykład następująca reguła oparta na zapytaniach używa reguł bezpieczeństwa opartych na użytkownikach i reguł opartych na zapytaniach w celu ograniczenia dostępu do danych w kolekcji baskets tylko do koszyków, które posiada aktywny użytkownik:

"baskets": {
  ".read": "auth.uid != null &&
            query.orderByChild == 'owner' &&
            query.equalTo == auth.uid" // restrict basket access to owner of basket
}

Następujące zapytanie, które zawiera parametry zapytania w regule, zakończy się powodzeniem:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

Jednak zapytania, które nie zawierają parametrów w regule, zakończyłyby się niepowodzeniem z błędem PermissionDenied :

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

Możesz również użyć reguł opartych na zapytaniach, aby ograniczyć ilość danych, które klient pobiera za pomocą operacji odczytu.

Na przykład następująca reguła ogranicza dostęp do odczytu tylko do pierwszych 1000 wyników zapytania, uporządkowanych według priorytetu:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

Następujące query. wyrażenia są dostępne w Regułach bazy danych czasu rzeczywistego.

Wyrażenia reguł oparte na zapytaniach
Wyrażenie Rodzaj Opis
query.orderByKey
query.orderByPriority
query.orderByValue
boolean Prawda dla zapytań uporządkowanych według klucza, priorytetu lub wartości. W przeciwnym razie fałsz.
query.orderByChild strunowy
zero
Użyj ciągu, aby przedstawić ścieżkę względną do węzła podrzędnego. Na przykład query.orderByChild == "address/zip" . Jeśli zapytanie nie jest uporządkowane przez węzeł podrzędny, ta wartość jest null.
query.startAt
query.endAt
query.equalTo
strunowy
numer
boolean
zero
Pobiera granice wykonywanego zapytania lub zwraca wartość null, jeśli nie ma zestawu powiązań.
query.limitToFirst
query.limitToLast
numer
zero
Pobiera limit wykonywania zapytania lub zwraca wartość null, jeśli nie ma ustawionego limitu.

Operatorzy

Reguły bazy danych czasu rzeczywistego obsługują wiele operatorów, których można używać do łączenia zmiennych w instrukcji warunku. Zobacz pełną listę operatorów w dokumentacji referencyjnej .

Tworzenie warunków

Twoje rzeczywiste warunki będą się różnić w zależności od dostępu, który chcesz przyznać. Reguły celowo oferują olbrzymi stopień elastyczności, więc reguły aplikacji mogą być ostatecznie tak proste lub tak złożone, jak potrzebujesz.

Aby uzyskać wskazówki dotyczące tworzenia prostych, gotowych do produkcji reguł, zobacz Podstawowe reguły zabezpieczeń .