Strukturyzacja reguł bezpieczeństwa Cloud Firestore

Reguły bezpieczeństwa Cloud Firestore pozwalają kontrolować dostęp 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łącz tę składnię z warunkami reguł bezpieczeństwa, aby stworzyć kompletne zestawy 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 {
    // ...
  }
}

Deklaracja service cloud.firestore zakres reguł do Cloud Firestore, zapobiegając konfliktom między regułami bezpieczeństwa Cloud Firestore a regułami dla innych produktów, takich jak Cloud Storage.

Deklaracja match /databases/{database}/documents określa, że ​​reguły powinny być zgodne z dowolną bazą danych Cloud Firestore w projekcie. Obecnie każdy projekt ma tylko jedną bazę danych o nazwie (default) .

Podstawowe zasady odczytu/zapisu

Podstawowe zasady składają się z wyrażenia match określającego ścieżkę dokumentu oraz wyrażenia allow określającego szczegółowo, kiedy odczyt określonych danych jest dozwolony:

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. Wyrażenie match może wskazywać na konkretny 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 czy /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 .

Operacje granularne

W niektórych sytuacjach przydatne jest rozbicie read i write na bardziej szczegółowe operacje. Na przykład Twoja aplikacja może chcieć wymusić inne warunki przy tworzeniu dokumentu niż przy usuwaniu dokumentu. Możesz też zezwolić na odczyty pojedynczych dokumentów, ale odmówić dużych zapytań.

Reguła read może być podzielona na get i list , podczas gdy regułę write można podzielić 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 bezpieczeństwa 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 obowiązują 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 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 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=**} . 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 używania rekurencyjnej składni symboli wieloznacznych zmienna wieloznaczna będzie zawierać cały pasujący segment ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonej 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 zestawienia meczowego.

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 z dowolnych podzbiorów oraz dokumenty z 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, transakcji i zapisów wsadowych wielu dokumentów. 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 bezpieczeństwa 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 ze swoich 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.

Następne kroki