Cloud Firestore Güvenlik Kurallarını Yapılandırma

Cloud Firestore Güvenlik Kuralları, veritabanınızdaki belgelere ve koleksiyonlara erişimi kontrol etmenize olanak tanır. Esnek kurallar sözdizimi, tüm yazma işlemlerinden tüm veritabanına ve belirli bir belgedeki işlemlere kadar her şeyle eşleşen kurallar oluşturmanıza olanak tanır.

Bu kılavuz, güvenlik kurallarının temel sözdizimini ve yapısını açıklar. Eksiksiz kural kümeleri oluşturmak için bu sözdizimini güvenlik kuralları koşullarıyla birleştirin.

Hizmet ve veritabanı beyanı

Cloud Firestore Güvenlik Kuralları her zaman aşağıdaki bildirimle başlar:

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

service cloud.firestore bildirimi, kuralların kapsamını Cloud Firestore'a vererek, Cloud Firestore Güvenlik Kuralları ile Cloud Storage gibi diğer ürünlerin kuralları arasındaki çakışmaları önler.

match /databases/{database}/documents eşleşmesi bildirimi, kuralların projedeki herhangi bir Cloud Firestore veritabanıyla eşleşmesi gerektiğini belirtir. Şu anda her projenin (default) adlı yalnızca tek bir veritabanı vardır.

Temel okuma/yazma kuralları

Temel kurallar, bir belge yolunu belirten bir match ifadesinden ve belirtilen verilerin okunmasına izin verildiğinde ayrıntı veren bir allow ifadesinden oluşur:

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

Tüm eşleşme ifadeleri koleksiyonları değil belgeleri göstermelidir. Bir eşleşme ifadesi, match /cities/SF olduğu gibi belirli bir belgeye işaret edebilir veya match /cities/{city} gibi belirtilen yoldaki herhangi bir belgeye işaret etmek için joker karakterler kullanabilir.

Yukarıdaki örnekte, eşleşme ifadesi {city} joker karakter sözdizimini kullanır. Bu, kuralın /cities/SF veya /cities/NYC gibi cities koleksiyonundaki herhangi bir belge için geçerli olduğu anlamına gelir. Eşleşme ifadesindeki allow ver ifadeleri değerlendirildiğinde, city değişkeni, SF veya NYC gibi şehir belgesi adına çözümlenecektir.

Granüler işlemler

Bazı durumlarda, read ve write işlemlerini daha ayrıntılı işlemlere ayırmak yararlıdır. Örneğin, uygulamanız belge oluşturmada belge silmeden farklı koşullar uygulamak isteyebilir. Veya tek belge okumalarına izin vermek, ancak büyük sorguları reddetmek isteyebilirsiniz.

Bir read kuralı get ve list olarak bölünebilirken, bir write kuralı create , update ve delete olarak ayrılabilir:

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

hiyerarşik veriler

Cloud Firestore'daki veriler, belge koleksiyonları halinde düzenlenir ve her belge, hiyerarşiyi alt koleksiyonlar aracılığıyla genişletebilir. Güvenlik kurallarının hiyerarşik verilerle nasıl etkileşime girdiğini anlamak önemlidir.

cities koleksiyonundaki her belgenin bir landmarks alt koleksiyonunu içerdiği durumu düşünün. Güvenlik kuralları yalnızca eşleşen yolda geçerlidir, bu nedenle cities koleksiyonunda tanımlanan erişim kontrolleri, landmarks alt koleksiyonuna uygulanmaz. Bunun yerine, alt koleksiyonlara erişimi kontrol etmek için açık kurallar yazın:

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

match match yolu her zaman dış match ifadesinin yoluna göredir. Bu nedenle aşağıdaki kural kümeleri eşdeğerdir:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}
tutucu5 l10n-yer
service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

özyinelemeli joker karakterler

Kuralların keyfi olarak derin bir hiyerarşiye uygulanmasını istiyorsanız, {name=**} yinelemeli joker sözdizimini kullanın. Örneğin:

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

Özyinelemeli joker sözdizimini kullanırken, joker karakter değişkeni, belge derinlemesine iç içe geçmiş bir alt koleksiyonda bulunsa bile eşleşen yol bölümünün tamamını içerecektir. Örneğin, yukarıda listelenen kurallar /cities/SF/landmarks/coit_tower bulunan bir belgeyle eşleşir ve document değişkeninin değeri SF/landmarks/coit_tower .

Ancak yinelemeli joker karakterlerin davranışının kural sürümüne bağlı olduğunu unutmayın.

Versiyon 1

Güvenlik kuralları varsayılan olarak sürüm 1'i kullanır. Sürüm 1'de, özyinelemeli joker karakterler bir veya daha fazla yol öğesiyle eşleşir. Boş bir yolla match /cities/{city}/{document=**} eşleşmesi alt koleksiyonlardaki belgelerle eşleşir ancak cities koleksiyonunda eşleşmez, oysa match /cities/{document=**} eşleşmedeki her iki belgeyle de eşleşir. cities koleksiyonu ve alt koleksiyonları.

Özyinelemeli joker karakterler, bir eşleşme ifadesinin sonunda gelmelidir.

Versiyon 2

Güvenlik kurallarının 2. versiyonunda, özyinelemeli joker karakterler sıfır veya daha fazla yol öğesiyle eşleşir. match/cities/{city}/{document=**} , herhangi bir alt koleksiyondaki belgelerle ve cities koleksiyonundaki belgelerle eşleşir.

rules_version = '2'; ekleyerek sürüm 2'ye kaydolmalısınız. güvenlik kurallarınızın en üstünde:

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

Her eşleşme ifadesi için en fazla bir özyinelemeli joker karakteriniz olabilir, ancak sürüm 2'de bu joker karakteri eşleşme ifadesinin herhangi bir yerine yerleştirebilirsiniz. Örneğin:

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

Koleksiyon grubu sorguları kullanıyorsanız , sürüm 2'yi kullanmanız gerekir, bkz. koleksiyon grubu sorgularının güvenliğini sağlama .

Çakışan eşleşme ifadeleri

Bir belgenin birden fazla match ifadesi ile eşleşmesi mümkündür. Birden çok allow ifadesinin bir istekle eşleşmesi durumunda, koşullardan herhangi biri true erişime izin verilir:

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

Yukarıdaki örnekte, cities koleksiyonuna yapılan tüm okuma ve yazma işlemlerine izin verilecektir, çünkü birinci kural her zaman false olsa bile ikinci kural her zaman true .

Güvenlik kuralı sınırları

Güvenlik kurallarıyla çalışırken aşağıdaki sınırlara dikkat edin:

sınır Detaylar
İstek başına maksimum exists() , get() ve getAfter() çağrı sayısı
  • Tek belge istekleri ve sorgu istekleri için 10.
  • Çoklu belge okumaları, işlemler ve toplu yazma işlemleri için 20. Önceki 10 sınırı da her işlem için geçerlidir.

    Örneğin, 3 yazma işlemiyle toplu bir yazma isteği oluşturduğunuzu ve güvenlik kurallarınızın her bir yazmayı doğrulamak için 2 belge erişim çağrısı kullandığını hayal edin. Bu durumda, her yazma 10 erişim çağrısından 2'sini kullanır ve toplu yazma isteği, 20 erişim çağrısından 6'sını kullanır.

Her iki sınırın da aşılması, izin reddedildi hatasıyla sonuçlanır.

Bazı belge erişim aramaları önbelleğe alınabilir ve önbelleğe alınan aramalar sınırlara dahil edilmez.

Maksimum iç içe match ifadesi derinliği 10
Bir dizi iç içe match ifadesi içinde izin verilen yol segmentlerinde maksimum yol uzunluğu 100
Bir dizi iç içe match ifadesi içinde izin verilen maksimum yol yakalama değişkeni sayısı 20
Maksimum işlev çağrısı derinliği 20
Maksimum işlev bağımsız değişkeni sayısı 7
İşlev başına maksimum let değişken bağlama sayısı 10
Maksimum özyinelemeli veya döngüsel işlev çağrısı sayısı 0 (izin verilmez)
İstek başına değerlendirilen maksimum ifade sayısı 1.000
Bir kural kümesinin maksimum boyutu Kural kümeleri iki boyut sınırına uymalıdır:
  • Firebase konsolundan veya firebase deploy yayınlanan kural kümesi metin kaynağının boyutunda 256 KB'lik bir sınır.
  • Firebase kaynağı işlediğinde ve onu arka uçta etkinleştirdiğinde ortaya çıkan, derlenmiş kural kümesinin boyutuna ilişkin 250 KB'lik bir sınır.

Sonraki adımlar