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

Cloud Firestore Security Rules veritabanınızdaki dokümanlara ve koleksiyonlara erişimi kontrol etmenize olanak tanır. Esnek kurallar söz dizimi, tüm yazma işlemlerinden veritabanının tamamına ve belirli bir dokümandaki işlemlere kadar her şeyi eşleştiren kurallar oluşturmanıza olanak tanır.

Bu kılavuzda, güvenlik kurallarının temel söz dizimi ve yapısı açıklanmaktadır. Bu söz dizimini güvenlik kuralları koşullarıyla birleştirerek eksiksiz kural kümeleri oluşturun.

Hizmet ve veritabanı beyanı

Cloud Firestore Security Rules her zaman aşağıdaki beyanla başlar:

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

service cloud.firestore bildirimi, kuralların kapsamını Cloud Firestore ile sınırlar. Böylece Cloud Firestore Security Rules ile Cloud Storage gibi diğer ürünlerin kuralları arasında çakışma yaşanmaz.

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

Temel okuma/yazma kuralları

Temel kurallar, bir doküman yolunu belirten bir match ifadesinden ve belirtilen verilerin okunmasına ne zaman izin verildiğini ayrıntılı olarak açıklayan 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 koleksiyonlara değil, dokümanlara işaret etmelidir. Bir eşleşme ifadesi, match /cities/SF örneğinde olduğu gibi belirli bir dokümanı işaret edebilir veya match /cities/{city} örneğinde olduğu gibi belirtilen yoldaki herhangi bir dokümanı işaret etmek için joker karakterler kullanabilir.

Yukarıdaki örnekte, eşleşme ifadesinde {city} joker karakter söz dizimi kullanılmaktadır. Bu, kuralın cities koleksiyonundaki tüm dokümanlar (ör. /cities/SF veya /cities/NYC) için geçerli olduğu anlamına gelir. Eşleşme ifadesindeki allow ifadeleri değerlendirildiğinde city değişkeni, şehir dokümanı adına (ör. SF veya NYC) dönüşür.

Ayrıntılı işlemler

Bazı durumlarda, read ve write işlemlerini daha ayrıntılı işlemlere ayırmak faydalı olur. Örneğin, uygulamanız belge oluşturma ve belge silme işlemlerinde farklı koşullar uygulamak isteyebilir. Tek doküman okumalarına izin verip büyük sorguları reddetmek de isteyebilirsiniz.

read kuralı get ve list olarak, write kuralı ise 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 içindeki veriler belge koleksiyonları halinde düzenlenir ve her belge, alt koleksiyonlar aracılığıyla hiyerarşiyi genişletebilir. Güvenlik kurallarının hiyerarşik verilerle nasıl etkileşime girdiğini anlamak önemlidir.

cities koleksiyonundaki her dokümanın bir landmarks alt koleksiyonu içerdiği durumu ele alalım. Güvenlik kuralları yalnızca eşleşen yolda geçerlidir. Bu nedenle, cities koleksiyonunda tanımlanan erişim kontrolleri landmarks alt koleksiyonu için geçerli değildir. 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 ifadeleri iç içe yerleştirildiğinde, içteki match ifadesinin yolu her zaman dıştaki match ifadesinin yoluna göre belirlenir. 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>;
    }
  }
}

Yinelemeli joker karakterler

Kuralların rastgele derinlikteki bir hiyerarşiye uygulanmasını istiyorsanız yinelemeli joker karakter söz dizimini ({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 dizimi kullanılırken, doküman derinlemesine iç içe yerleştirilmiş bir alt koleksiyonda bulunsa bile joker karakter değişkeni eşleşen yol segmentinin tamamını içerir. Örneğin, yukarıda listelenen kurallar /cities/SF/landmarks/coit_tower konumundaki bir belgeyle eşleşir ve document değişkeninin değeri SF/landmarks/coit_tower olur.

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

Sürüm 1

Güvenlik kuralları varsayılan olarak 1. sürümü kullanır. 1. sürümde, yinelemeli joker karakterler bir veya daha fazla yol öğesiyle eşleşir. Boş bir yolla eşleşmezler. Bu nedenle, match /cities/{city}/{document=**}, alt koleksiyonlardaki belgelerle eşleşir ancak cities koleksiyonundaki belgelerle eşleşmez. match /cities/{document=**} ise hem cities koleksiyonundaki hem de alt koleksiyonlardaki belgelerle eşleşir.

Yinelemeli joker karakterler, eşleşme ifadesinin sonunda yer almalıdır.

Sürüm 2

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

Güvenlik kurallarınızın en üstüne rules_version = '2'; ekleyerek 2. sürümü etkinleştirmeniz gerekir:

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 yinelemeli joker karakter kullanabilirsiniz. Ancak 2. sürümde 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 2. sürümü kullanmanız gerekir. Koleksiyon grubu sorgularının güvenliğini sağlama başlıklı makaleyi inceleyin.

Ç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ştiği durumlarda, koşullardan herhangi biri true ise 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 false olsa da ikinci kural her zaman true olduğundan cities koleksiyonuna yapılan tüm okuma ve yazma işlemlerine izin verilir.

Güvenlik kuralı sınırları

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

Sınır Ayrıntılar
İstek başına maksimum exists(), get() ve getAfter() çağrısı sayısı
  • Tek belgeli istekler ve sorgu istekleri için 10.
  • Çok belgeli okumalar, işlemler ve toplu yazmalar için 20. Her işlemde yukarıdaki 10 sınırı da geçerlidir.

    3 yazma işlemiyle bir toplu yazma isteği oluşturduğunuzu ve güvenlik kurallarınızın her yazma işlemini doğrulamak için 2 belge erişimi çağrısı kullandığını varsayalım. Bu durumda her yazma işlemi 10 erişim çağrısından 2'sini; toplu yazma isteği ise 20 erişim çağrısından 6'sını kullanır.

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

Bazı belge erişimi çağrıları önbelleğe alınabilir. Önbelleğe alınan çağrılar sınırlamaya dahil edilmez.

Maksimum iç içe yerleştirilen match ifadesi derinliği 10
Yol segmentlerinde, iç içe yerleştirilmiş bir grup match ifadesinde izin verilen maksimum yol uzunluğu 100
İç içe yerleştirilen bir grup 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 maksimum let işlev bağlama sayısı 10
Maksimum yinelenen veya döngüsel işlev çağrısı sayısı 0 &lpar;izin verilmez&rpar;
İstek başına değerlendirilen maksimum ifade sayısı 1.000
Maksimum kural grubu boyutu Kural grupları iki boyut sınırına uymalıdır:
  • Firebase konsolundan veya firebase deploy ile CLI'den yayınlanan kural grubu metin kaynağının boyutu için 256 KB sınır.
  • Firebase, kaynağı işlediğinde ve arka uçta etkinleştirdiğinde ortaya çıkan derlenmiş kural grubunun boyutu için 250 KB sınır.

Sonraki adımlar