Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Strukturyzacja reguł bezpieczeństwa Cloud Firestore

Reguły zabezpieczeń Cloud Firestore umożliwiają kontrolę dostępu do dokumentów i zbiorów w Twojej bazie danych. Elastyczna składnia reguł umożliwia tworzenie reguł, które pasują do wszystkiego, od wszystkich zapisów do całej bazy danych po operacje na określonym dokumencie.

Ten przewodnik opisuje podstawową składnię i strukturę reguł bezpieczeństwa. Połączyć tę składnię z zasad bezpieczeństwa warunków do tworzenia kompletnych zestawów reguł.

Deklaracja usług i bazy danych

Reguły bezpieczeństwa Cloud Firestore zawsze zaczynają się od następującej deklaracji:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

service cloud.firestore deklaracja celownicze zasady do Cloud FireStore, zapobieganie konfliktom między chmurze zasad bezpieczeństwa i przepisów FireStore dla innych produktów, takich jak Cloud Storage.

W match /databases/{database}/documents deklaracja określa, że przepisy powinny pasować do dowolnej bazy danych Chmura FireStore w projekcie. Obecnie każdy projekt ma tylko jedną bazę danych o nazwie (default) .

Podstawowe zasady odczytu/zapisu

Podstawowe reguły składają się z match oświadczenie określające ścieżkę dokumentów oraz allow wyrażenie szczegółowo podczas czytania podanych danych jest dozwolone:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Wszystkie stwierdzenia zgodności powinny wskazywać na dokumenty, a nie kolekcje. Oświadczenie mecz może wskazywać na konkretnego dokumentu, jak w match /cities/SF lub używać symboli wieloznacznych do punktu do dowolnego dokumentu w określonej ścieżce, tak jak w match /cities/{city} .

W powyższym przykładzie, oświadczenie mecz używa {city} składni wieloznaczny. Oznacza to, że reguła ma zastosowanie do każdego dokumentu w cities kolekcji, takich jak /cities/SF lub /cities/NYC . Gdy allow wyrażeń w rachunku meczu są wyliczone, city zmienna będzie rozwiązać nazwy dokumentu miasta, takich jak SF lub NYC .

Operacje granularne

W niektórych sytuacjach jest to przydatne do rozbicia read i write do operacji bardziej ziarnistych. Na przykład aplikacja może chcieć wymusić inne warunki podczas tworzenia dokumentu niż podczas usuwania dokumentu. Możesz też zezwolić na odczyty pojedynczych dokumentów, ale odmówić dużych zapytań.

read reguła może zostać podzielone na get i list , podczas gdy write reguła może zostać podzielony na create , update i delete :

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

Dane hierarchiczne

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żmy sytuację, w której każdy dokument w cities kolekcji zawiera landmarks subcollection. Zasady bezpieczeństwa stosuje się jedynie przy dopasowanej ścieżki, więc kontrole dostępu zdefiniowane w cities kolekcji nie stosuje się do landmarks subcollection. 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>;
        }
    }
  }
}

Kiedy zagnieżdżanie match oświadczenia, ścieżka wewnętrznej match oświadczenia jest zawsze w stosunku do toru zewnętrznego match oświadczeniu. 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 zasady stosuje się do dowolnie głębokie hierarchii, należy użyć składni, rekurencyjną wieloznaczny {name=**} . Na przykład:

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, zasady wymienione powyżej byłoby dopasować dokument znajdujący się w /cities/SF/landmarks/coit_tower , a wartość document zmiennej byłoby 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. Oni nie pasują pustą ścieżkę, więc match /cities/{city}/{document=**} mecze dokumentów w podkolekcji ale nie w cities kolekcji, podczas match /cities/{document=**} pasuje zarówno dokumenty w cities zbieranie i podkolekcjach.

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=**} mecze dokumentów w dowolnym podkolekcji jak również dokumentów w cities kolekcji.

Musisz zgłosić się do wersji 2 poprzez dodanie 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 korzystasz z grupy kwerend kolekcji , należy użyć wersji 2, zobacz zabezpieczania zapytań grupowych kolekcja .

Pokrywające się stwierdzenia dotyczące dopasowania

Jest to możliwe, dokument, aby dopasować więcej niż jeden match oświadczenie. W przypadku wielokrotnego allow wyrażenia dopasować żądanie, dostęp jest dozwolony, jeżeli 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 do cities kolekcji będą mogły ponieważ druga zasada jest zawsze true , choć pierwsza zasada 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 exists() , get() , a getAfter() zwraca 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 zagnieżdżona match głębokość oświadczenie 10
Maksymalna długość ścieżki w segmentach ścieżki, dozwolone w obrębie zestawu zagnieżdżonych match sprawozdania 100
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolone w obrębie zestawu zagnieżdżonych match sprawozdania 20
Maksymalna głębokość wywołania funkcji 20
Maksymalna liczba argumentów funkcji 7
Maksymalna liczba let zmiennych wiązań na funkcji 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:
  • limit 256 KB na wielkości zestawu reguł źródła tekstu opublikowanego w konsoli Firebase lub z CLI używając firebase deploy .
  • limit 250 KB rozmiaru skompilowanego zestawu reguł, który powstaje, gdy Firebase przetwarza źródło i uaktywnia je na zapleczu.

Następne kroki