Tworzenie struktury reguł zabezpieczeń Cloud Firestore

Reguły zabezpieczeń Cloud Firestore pozwalają kontrolować dostęp do dokumentów oraz w swojej bazie danych. Elastyczna składnia reguł umożliwia reguły, które pasują do wszystkiego, od wszystkich zapisów przez całą bazę danych po operacje w określonym dokumencie.

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

Deklaracja dotycząca usługi i bazy danych

Reguły zabezpieczeń Cloud Firestore zawsze zaczynają się od tej deklaracji:

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

Deklaracja service cloud.firestore ogranicza reguły do zakresu Cloud Firestore, co zapobiega konfliktom między regułami zabezpieczeń Cloud Firestore reguł dla innych usług, takich jak Cloud Storage.

Deklaracja match /databases/{database}/documents określa, że reguły powinny pasują do dowolnej bazy danych Cloud Firestore w projekcie. Obecnie każdy projekt ma tylko jedną bazę danych o nazwie (default).

Podstawowe reguły odczytu/zapisu

Podstawowe reguły składają się z instrukcji match określającej ścieżkę dokumentu i wyrażenie allow określające szczegóły podczas odczytu określonych 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 instrukcje dopasowania powinny wskazywać dokumenty, a nie kolekcje. Dopasowanie instrukcja może wskazywać konkretny dokument, na przykład match /cities/SF, lub użyć symboli wieloznacznych na dowolny dokument w określonej ścieżce, np. match /cities/{city}.

W przykładzie powyżej instrukcja dopasowania używa składni z symbolem wieloznacznym {city}. Oznacza to, że reguła ma zastosowanie do wszystkich dokumentów w kolekcji cities, na przykład /cities/SF lub /cities/NYC. Gdy wyrażenia allow w instrukcji dopasowania to analizowana, zmienna city przyjmie nazwę dokumentu miasta, na przykład SF lub NYC.

Operacje szczegółowe

W niektórych sytuacjach warto podzielić read i write na bardziej szczegółowe do bardziej szczegółowych działań. Aplikacja może na przykład wymuszać w aplikacji różne warunków tworzenia dokumentu niż przy jego usunięciu. Możesz też zezwala na odczyt pojedynczego dokumentu, ale odrzuca duże zapytania.

Regułę read można podzielić na get i list, a regułę write – zostanie 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 z nich dokument może rozszerzyć hierarchię za pomocą kolekcji podrzędnych. Ważne jest, zrozumieć, jak reguły zabezpieczeń współdziałają z danymi hierarchicznymi.

Weźmy pod uwagę sytuację, w której każdy dokument w kolekcji cities zawiera element landmarks kolekcja podrzędna. Reguły zabezpieczeń są stosowane tylko w przypadku dopasowanej ścieżki, więc kontrole dostępu zdefiniowane w kolekcji cities nie mają zastosowania do landmarks kolekcja podrzędna. Zamiast tego utwórz jawne 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>;
        }
    }
  }
}

Gdy zagnieżdżasz instrukcje match, ścieżka wewnętrznej instrukcji match wynosi zawsze w stosunku do ścieżki zewnętrznej instrukcji match. Te zestawy reguł są więc 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łębszej hierarchii, użyj funkcji rekurencyjna składnia symbolu wieloznacznego, {name=**}. 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>;
    }
  }
}

Jeśli używasz składni rekurencyjnego symbolu wieloznacznego, zmienna z symbolem wieloznacznym będzie zawierać parametr całego pasującego segmentu ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonym podkolekcja. Na przykład wymienione powyżej reguły będą pasować dokumentu znajdującego się pod adresem /cities/SF/landmarks/coit_tower, a wartość zmienna document będzie miała wartość SF/landmarks/coit_tower.

Pamiętaj jednak, że działanie rekurencyjnych symboli wieloznacznych zależy od reguł wersji.

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ń dotyczących grup kolekcji, musisz stosować parametry w wersji 2 znajdziesz informacje na temat zabezpieczania zapytań dotyczących grup kolekcji.

Nakładające się instrukcje dopasowania

Dokument może pasować do więcej niż jednej instrukcji match. W jeśli do żądania pasuje wiele wyrażeń allow, 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ą jest dozwolona, ponieważ druga reguła ma zawsze wartość true, mimo że pierwsza ma zawsze wartość false.

Limity reguł zabezpieczeń

Podczas pracy z regułami zabezpieczeń pamiętaj o tych ograniczeniach:

Dalsze kroki

• Utwórz niestandardowe warunki reguł zabezpieczeń.
• Zapoznaj się z informacjami o regułach zabezpieczeń.