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ł.

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

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:

Następne kroki

• Zapis zwyczaj rządzi warunków bezpieczeństwa .
• Przeczytać odniesienie zasad bezpieczeństwa .