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, veritabanının tamamına yapılan tüm yazma işlemlerinden belirli bir belgedeki 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öz dizimi ve yapısı açıklanmaktadır. Tam kural kümeleri oluşturmak için bu söz dizimini güvenlik kuralı koşulları ile birleştirin.

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 beyanı, kuralları Cloud Firestore olarak tanımlar. Böylece, Cloud Firestore Security Rules ile Cloud Storage gibi diğer ürünlere ait kurallar arasında çakışmalar önlenir.

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

Temel okuma/yazma kuralları

Temel kurallar, bir doküman yolunu belirten bir match ifadesi ve belirtilen verilerin ne zaman okunmasına izin verildiğini ayrıntılarıyla 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. Eşleşme ifadesi, match /cities/SF'te olduğu gibi belirli bir dokümanı işaretleyebilir veya match /cities/{city}'te olduğu gibi belirtilen yoldaki herhangi bir dokümanı işaretlemek için joker karakterler kullanabilir.

Yukarıdaki örnekte, eşleme ifadesi {city} joker karakter söz dizimini kullanı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şleme ifadesindeki allow ifadeleri değerlendirildiğinde city değişkeni, SF veya NYC gibi şehir dokümanı adına çözümlenir.

Ayrıntılı işlemler

Bazı durumlarda read ve write'ü daha ayrıntılı işlemlere ayırmak faydalı olabilir. Örneğin, uygulamanız belge oluşturma işleminde belge silme işleminden farklı koşullar uygulamak isteyebilir. Dilerseniz tek belge okumalarına izin verebilir ancak büyük sorguları reddedebilirsiniz.

read kuralı get ve list olarak, write kuralı ise create, update ve delete olarak bölünebilir:

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'teki 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 belgenin bir landmarks alt koleksiyon içerdiğini varsayalım. Güvenlik kuralları yalnızca eşleşen yolda geçerli olduğundan cities koleksiyonunda tanımlanan erişim denetimleri landmarks alt koleksiyonunda 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ştirilirken iç match ifadesinin 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>;
      }
    }
  }
}

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

Yinelemeli joker karakterler

Kuralların keyfi olarak derin bir hiyerarşiye uygulanmasını istiyorsanız yinelenen 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>;
    }
  }
}

Yinelenen joker karakter söz dizimi kullanıldığında, joker karakter değişkeni, doküman derinlemesine iç içe yerleştirilmiş bir alt koleksiyonda yer alsa bile eşleşen yol segmentinin tamamını içerir. Örneğin, yukarıda listelenen kurallar /cities/SF/landmarks/coit_tower konumunda bulunan bir belgeyle eşleşecek ve document değişkeninin değeri SF/landmarks/coit_tower olacaktır.

Ancak yinelenen 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, yinelenen joker karakterler bir veya daha fazla yol öğesiyle eşleşir. Boş bir yola eşleşmezler. Bu nedenle match /cities/{city}/{document=**}, cities koleksiyonundaki değil, alt koleksiyonlardaki belgelerle eşleşir. match /cities/{document=**} ise hem cities koleksiyonundaki hem de alt koleksiyonlardaki belgelerle eşleşir.

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

Sürüm 2

Güvenlik kurallarının 2. sürümünde, yinelenen joker karakterler sıfır veya daha fazla yol öğesiyle eşleşir. match/cities/{city}/{document=**}, tüm alt koleksiyonlardaki dokümanların yanı sıra cities koleksiyonundaki dokümanlarla 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 yinelenen joker karakteriniz olabilir ancak 2 sürümünde 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, aşağıdaki koşullardan truebiri geçerliyse 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 bile ikinci kural her zaman true olduğu için 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