Google is committed to advancing racial equity for Black communities. See how.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Struktura reguł bezpieczeństwa Cloud Firestore

Reguły bezpieczeństwa Cloud Firestore pozwalają kontrolować dostęp do dokumentów i kolekcji w bazie danych. Elastyczna składnia reguł umożliwia tworzenie reguł pasujących do wszystkiego, od wszystkich zapisów do całej bazy danych po operacje na określonym dokumencie.

W tym przewodniku opisano podstawową składnię i strukturę reguł bezpieczeństwa. Połącz tę składnię z warunkami reguł bezpieczeństwa, aby utworzyć kompletne zestawy reguł.

Deklaracja usługi 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 ogranicza reguły 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 pasować do dowolnej bazy danych Cloud 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 instrukcji match , określającej ścieżkę do dokumentu i wyrażenia allow szczegółowo opisują, 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 dopasowania powinny wskazywać na dokumenty, a nie kolekcje. Instrukcja dopasowania może wskazywać na konkretny dokument, np. match /cities/SF lub użyć symboli wieloznacznych, aby wskazać dowolny dokument w określonej ścieżce, np. match /cities/{city} .

W powyższym przykładzie instrukcja match używa składni wieloznacznej {city} . Oznacza to, że zasada ma zastosowanie do każdego dokumentu w kolekcji cities , takiego jak /cities/SF lub /cities/NYC . Gdy wyrażenia allow w instrukcji dopasowania są oceniane, zmienna city zostanie rozstrzygnięta na nazwę dokumentu miasta, na przykład SF lub NYC .

Granularne operacje

W niektórych sytuacjach warto podzielić read i write na bardziej szczegółowe operacje. Na przykład Twoja aplikacja może chcieć wymusić inne warunki przy tworzeniu dokumentów niż przy ich usuwaniu. Lub możesz zezwolić na odczytywanie pojedynczego dokumentu, ale odmawiać dużych zapytań.

Regułę read można podzielić 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ę za pomocą podkolekcji. Ważne jest, aby zrozumieć, w jaki sposób reguły bezpieczeństwa współdziałają z danymi hierarchicznymi.

Rozważmy sytuację, w której każdy dokument w kolekcji cities zawiera podkolekcję 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 kontrolujące 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 instrukcji match wewnętrznego jest zawsze względna w stosunku do ścieżki instrukcji match zewnętrznego. Następujące 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>;
    }
  }
}
 

Rekursywne symbole wieloznaczne

Jeśli chcesz, aby reguły miały zastosowanie do arbitralnie głębokiej hierarchii, użyj rekurencyjnej składni wieloznacznej, {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 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 kolekcji podrzędnej. 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 rekursywnych symboli wieloznacznych zależy od wersji reguł.

Wersja 1

Reguły bezpieczeństwa domyślnie używają wersji 1. W wersji 1 rekursywne symbole wieloznaczne pasują do co najmniej jednego elementu ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**} pasuje do dokumentów w podkolekcjach, ale nie w kolekcji cities , podczas gdy match /cities/{document=**} dopasowuje oba dokumenty w kolekcja cities i podkolekcje.

Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.

Wersja 2

W wersji 2 reguł bezpieczeństwa rekursywne symbole wieloznaczne odpowiadają zeru lub większej liczbie elementów ścieżki. match/cities/{city}/{document=**} dopasowuje dokumenty we wszystkich podkolekcjach, a także dokumenty w kolekcji cities .

Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2'; u góry reguł 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 rekursywny symbol wieloznaczny na każdą instrukcję dopasowania, ale w wersji 2 możesz umieścić ten symbol 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 zapytań o grupy kolekcji , musisz użyć wersji 2, zobacz zabezpieczanie zapytań o grupy kolekcji .

Pokrywające się stwierdzenia dopasowania

Dokument może pasować do więcej niż jednej instrukcji 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 exists() , get() , a getAfter() zwraca na żądanie
  • 10 dla wniosków o pojedyncze dokumenty i zapytań.
  • 20 dla odczytów wielu dokumentów, transakcji i zapisów wsadowych. Poprzedni limit 10 ma również zastosowanie do każdej operacji.

    Na przykład wyobraź sobie, że tworzysz wsadowe żądanie zapisu z 3 operacjami zapisu i że Twoje reguły bezpieczeństwa używają 2 wywołań dostępu do dokumentów w celu sprawdzenia każdego zapisu. W tym przypadku każdy zapis wykorzystuje 2 z 10 wywołań dostępu, a wsadowe żądanie zapisu wykorzystuje 6 z 20 wywołań dostępu.

Przekroczenie któregokolwiek z limitów powoduje błąd odmowy uprawnień.

Niektóre wywołania dostępu do dokumentów mogą być buforowane, a te z pamięci podręcznej nie wliczają się do limitów.

Maksymalna głębokość instrukcji match zagnieżdżonego 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 dozwolonych w zestawie zagnieżdżonych instrukcji match 20
Maksymalna głębokość wywołania funkcji 20
Maksymalna liczba argumentów funkcji 7
Maksymalna liczba powiązań zmiennej let na funkcję 10
Maksymalna liczba rekurencyjnych lub cyklicznych wywołań funkcji 0 (niedozwolone)
Maksymalna liczba wyrażeń ocenianych na żądanie 1000
Maksymalny rozmiar zestawu reguł Zestawy reguł Verax muszą przestrzegać dwóch ograniczeń rozmiaru:
  • limit 256 KB rozmiaru źródła tekstowego zestawu reguł Verax publikowanego z konsoli Firebase lub z interfejsu wiersza polecenia przy użyciu firebase deploy .
  • limit 250 KB rozmiaru skompilowanego zestawu reguł, który pojawia się, gdy Firebase przetwarza źródło Verax i uaktywnia je na zapleczu.

Następne kroki