Struktura 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ł pasujących do wszystkiego, od wszystkich zapisów do całej bazy danych po operacje na konkretnym 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ług i baz 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 obejmuje reguły Cloud Firestore, zapobiegając konfliktom między regułami bezpieczeństwa Cloud Firestore a regułami dotyczącymi 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ę dokumentu oraz wyrażenia allow określającego, kiedy dozwolone jest odczytywanie określonych danych:

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 instrukcje dopasowania powinny wskazywać na dokumenty, a nie kolekcje. Instrukcja match może wskazywać konkretny dokument, jak w przypadku match /cities/SF lub używać symboli wieloznacznych, aby wskazywać dowolny dokument w określonej ścieżce, jak w przypadku match /cities/{city} .

W powyższym przykładzie instrukcja match używa składni wieloznacznej {city} . Oznacza to, że reguła dotyczy dowolnego dokumentu w kolekcji cities , takiego jak /cities/SF lub /cities/NYC . Po ocenie wyrażeń allow w instrukcji match zmienna city zostanie zamieniona na nazwę dokumentu miasta, na przykład SF lub NYC .

Operacje granularne

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

Regułę read można podzielić na get i list , natomiast 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 podzbiory. 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 na dopasowanej ścieżce, więc kontrola dostępu zdefiniowana w kolekcji cities nie ma zastosowania do podkolekcji landmarks . Zamiast tego napisz jawne 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 wewnętrznej instrukcji match jest zawsze określana względem ścieżki zewnętrznej instrukcji match . Dlatego następujące zestawy reguł są 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 miały zastosowanie do dowolnie 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 stosowania 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 będą pasować do dokumentu znajdującego się w /cities/SF/landmarks/coit_tower , a wartość zmiennej document będzie wynosić 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 używasz zapytań do grup kolekcji , musisz użyć wersji 2, zobacz zabezpieczanie zapytań do grup kolekcji .

Nakładające się instrukcje dopasowania

Możliwe jest, że dokument będzie pasował do więcej niż jednej instrukcji match . W przypadku, gdy do żądania pasuje wiele wyrażeń allow , dostęp jest dozwolony, jeśli true jest którykolwiek z warunków:

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, należy zwrócić uwagę na następujące ograniczenia:

Następne kroki

• Napisz warunki niestandardowych reguł bezpieczeństwa .
• Przeczytaj odniesienia do reguł bezpieczeństwa .