Google, Siyah topluluklar için ırksal eşitliği ilerletmeye kararlıdır. Nasıl olduğunu gör.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

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

Cloud Firestore Güvenlik Kuralları, veritabanınızdaki belgelere ve koleksiyonlara erişimi kontrol etmenizi sağlar. Esnek kurallar sözdizimi, tüm yazma işlemlerinden veritabanının tamamına, 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çıklamaktadır. Tam 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 beyanla başlar:

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

service cloud.firestore bildirimi, Cloud Firestore Güvenlik Kuralları ile Cloud Storage gibi diğer ürünler için kurallar arasındaki çatışmaları önleyerek kuralları Cloud Firestore'a dahil eder.

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

Temel okuma / yazma kuralları

Temel kurallar oluşur match belge yolu belirterek beyanı ve allow verilir belirtilen verileri okurken ifade detaylandırma:

 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 dokümanları göstermelidir. Eşleşme ifadesi, match /cities/SF gibi belirli bir belgeyi işaret edebilir veya match /cities/{city} olduğu gibi belirtilen yoldaki herhangi bir belgeyi 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. Maç ifadesindeki allow ifadeleri değerlendirildiğinde, city değişkeni, SF veya NYC gibi şehir belgesi adına çözümlenir.

Granül 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şturma konusunda belge silme işleminden farklı koşullar uygulamak isteyebilir. Veya tek bir belgenin okunmasına izin vermek, ancak büyük sorguları reddetmek isteyebilirsiniz.

Bir read kuralı ayrılabilir get ve list bir süre, write kuralı ayrılabilir create , update ve 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>;
    }
  }
}
 

Hiyerarşik veriler

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

cities koleksiyonundaki her belgenin bir yer landmarks alt koleksiyonu 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 yer landmarks alt toplama için geçerli değildir. Bunun yerine, alt toplamalara 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>;
        }
    }
  }
}
 

Yuva yaparken match ifadeleri, iç yolu match deyimi daima dış yoluna akrabası match açıklamada. Bu nedenle aşağıdaki kural setleri 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 keyfi olarak derin bir hiyerarşiye uygulanmasını istiyorsanız, yinelenen joker karakter sözdizimini ( {name=**} . Ö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özdizimini kullanırken, joker karakter değişkeni, belge derin iç içe bir alt toplamada bulunsa bile eşleşen yol parçasının tamamını içerecektir. Örneğin, yukarıda listelenen kurallar /cities/SF/landmarks/coit_tower bulunan bir belgeyle /cities/SF/landmarks/coit_tower ve document değişkeninin değeri SF/landmarks/coit_tower .

Ancak, yinelenen 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, yinelemeli joker karakterler bir veya daha fazla yol öğesiyle eşleşir. Boş bir yolla match /cities/{city}/{document=**} , bu nedenle match /cities/{city}/{document=**} eşleşme, alt toplamalardaki belgeleri eşleştirir ancak cities koleksiyonuyla match /cities/{document=**} ; buna karşılık match /cities/{document=**} , cities toplama ve alt toplamalar.

Özyinelemeli joker karakterler bir maç ifadesinin sonuna gelmelidir.

Versiyon 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=**} herhangi bir alt toplamadaki dokümanlarla ve cities koleksiyonundaki dokümanlarla eşleşir.

rules_version = '2'; ekleyerek sürüm 2'ye rules_version = '2'; güvenlik kurallarınızın ü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>;
    }
  }
}
 

Maç başına en fazla bir özyinelemeli joker karaktere sahip olabilirsiniz, ancak sürüm 2'de bu joker karakteri maç bildiriminde herhangi bir yere 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; toplama grubu sorgularını koruma konusuna bakın.

Çakışan maç 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 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 kurallarına yapılan tüm okuma ve yazma işlemlerine izin verilecektir çünkü ikinci kural her zaman true , ancak birinci kural her zaman false .

Güvenlik kuralı sınırları

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

limit ayrıntılar
İstek başına maksimum exists() , get() ve getAfter() çağrısı sayısı
  • 10 tek belge istekleri ve sorgu istekleri için.
  • 20 çoklu belge okumaları, işlemleri ve toplu yazma işlemleri için. Önceki işlem 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ının 2'sini kullanır ve toplu yazma isteği 20 erişim çağrısının 6'sını kullanır.

Bu sınırlardan herhangi birinin aşılması, izin reddedildi hatasıyla sonuçlanır.

Bazı belge erişim çağrıları önbelleğe alınabilir ve önbellek çağrıları sınırlara dahil edilmez.

Maksimum iç içe match deyimi derinliği 10
Bir dizi iç içe match ifadesinde izin verilen yol bölümlerinde maksimum yol uzunluğu 100
Bir dizi iç içe match ifadesinde izin verilen maksimum yol yakalama değişkeni sayısı 20
Maksimum işlev çağrı 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 verilmiyor)
İstek başına değerlendirilen maksimum ifade sayısı 1.000
Kural kümesinin maksimum boyutu Verax kural kümeleri iki boyut sınırına uymalıdır:
  • firebase deploy konsolundan veya firebase deploy kullanılarak yayınlanan Verax kural firebase deploy metin kaynağının boyutu için 256 KB'lık bir sınırlama.
  • Firebase Verax kaynağını işlediğinde ve arka uçta etkinleştirdiğinde derlenen kural kümesinin boyutunda 250 KB'lık bir sınırlama.

Sonraki adımlar