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 kural sözdizimi, veritabanının tamamına yapılan tüm yazmalardan belirli bir belge üzerindeki işlemlere kadar her şeyle eşleşen kurallar oluşturmanıza olanak tanır.

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

Hizmet ve veritabanı bildirimi

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ı Cloud Firestore kapsamına alarak Cloud Firestore Güvenlik Kuralları ile Cloud Storage gibi diğer ürünlere ilişkin kurallar arasındaki çakışmaları önler.

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

Temel okuma/yazma kuralları

Temel kurallar, bir belge yolunu belirten bir match ifadesinden ve belirtilen veriler okunurken izin verilen ayrıntıyı veren bir allow verme 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 koleksiyonlara değil belgelere işaret etmelidir. Bir match ifadesi, match /cities/SF örneğinde olduğu gibi belirli bir belgeye işaret edebilir veya match /cities/{city} örneğinde olduğu gibi belirtilen yoldaki herhangi bir belgeye işaret etmek için joker karakterler kullanabilir.

Yukarıdaki örnekte, match ifadesi {city} joker karakter sözdizimini kullanır. Bu, kuralın cities koleksiyonundaki /cities/SF veya /cities/NYC gibi tüm belgeler için geçerli olduğu anlamına gelir. Match ifadesindeki allow ifadeler 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ı olabilir. Örneğin, uygulamanız belge oluşturmada belge silmeye göre farklı koşullar uygulamak isteyebilir. Veya tek bir belgenin okunmasına izin verip büyük sorguları reddetmek isteyebilirsiniz.

read kuralı get ve list olarak bölünebilirken, 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 koleksiyonu içerdiği durumu düşünün. Güvenlik kuralları yalnızca eşleşen yolda geçerli olduğundan, cities koleksiyonunda tanımlanan erişim denetimleri landmarks alt koleksiyonu için geçerli değildir. Bunun yerine alt koleksiyonlara erişimi denetlemek 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 ifadelerini iç içe yerleştirirken, içteki match ifadesinin yolu her zaman dıştaki 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>;
      }
    }
  }
}
service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

Özyinelemeli joker karakterler

Kuralların isteğe bağlı olarak derin bir hiyerarşiye uygulanmasını istiyorsanız, özyinelemeli joker karakter sözdizimini ( {name=**} 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 karakter söz dizimini kullanırken, joker karakter değişkeni, belge derinlemesine iç içe geçmiş bir alt koleksiyonda yer alsa 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 konumunda bulunan bir belgeyle eşleşir ve document değişkeninin değeri SF/landmarks/coit_tower olur.

Ancak özyinelemeli joker karakterlerin davranışının kuralların 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. Bunlar boş bir yolla eşleşmez, dolayısıyla match /cities/{city}/{document=**} alt koleksiyonlardaki belgelerle eşleşir ancak cities koleksiyonundaki belgelerle eşleşmez; match /cities/{document=**} ise alt koleksiyonlardaki belgelerle eşleşir cities koleksiyonu ve alt koleksiyonlar.

Tekrarlanan joker karakterler maç bildiriminin sonunda gelmelidir.

Versiyon 2

Güvenlik kurallarının 2. sürümünde, özyinelemeli joker karakterler sıfır veya daha fazla yol öğesiyle eşleşir. match/cities/{city}/{document=**} herhangi bir alt koleksiyondaki dokümanların yanı sıra cities koleksiyonundaki dokümanlarla da eşleşir.

rules_version = '2'; ekleyerek sürüm 2'ye dahil olmanız gerekir. 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>;
    }
  }
}

Eşleşme ifadesi başına en fazla bir özyinelemeli joker karaktere sahip olabilirsiniz, ancak sürüm 2'de bu joker karakteri, match 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 ifadesiyle eşleşmesi mümkündür. Birden fazla allow ifadesinin bir istekle eşleşmesi durumunda, koşullardan herhangi birinin true olması durumunda 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, ilk kural her zaman true olmasına rağmen ikinci kural her zaman false olduğundan cities koleksiyonuna yönelik tüm okuma ve yazma işlemlerine izin verilecektir.

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ısı sayısı
  • Tek belge istekleri ve sorgu istekleri için 10.
  • Çoklu belge okumaları, işlemler ve toplu yazmalar için 20. Önceki 10 sınırı her işlem için de geçerlidir.

    Örneğin, 3 yazma işlemiyle toplu bir yazma isteği oluşturduğunuzu ve güvenlik kurallarınızın her yazmayı doğrulamak için 2 belge erişim çağrısı kullandığını düşünün. 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 aşılması, izin reddedildi hatasıyla sonuçlanır.

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

Maksimum iç içe match bildirimi derinliği 10
Yol segmentlerindeki maksimum yol uzunluğuna, iç içe geçmiş match ifadeleri kümesinde izin verilir 100
Bir grup iç içe geçmiş match ifadesinde 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 let maksimum değişken bağlama sayısı 10
Maksimum sayıda özyinelemeli veya döngüsel işlev çağrısı 0 (izin verilmez)
İstek başına değerlendirilen maksimum ifade sayısı 1.000
Bir kural kümesinin maksimum boyutu Kural kümelerinin iki boyut sınırına uyması gerekir:
  • Firebase konsolundan veya firebase deploy kullanılarak CLI'den yayınlanan kural kümesi metin kaynağının boyutuna ilişkin 256 KB'lık bir sınır.
  • Firebase'in kaynağı işleyip arka uçta aktif hale getirmesiyle ortaya çıkan, derlenmiş kural kümesinin boyutunda 250 KB'lık bir sınır.

Sonraki adımlar