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
'yi daha ayrıntılı işlemlere ayırmak faydalı olabilir. Örneğin, uygulamanız belge oluşturma işlemi için 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 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'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 dokümanın bir landmarks
alt koleksiyonu 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 istediğiniz kadar 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 true
biri 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ı |
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 (izin verilmez) |
İ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:
|
Sonraki adımlar
- Özel güvenlik kuralları koşulları yazın.
- Güvenlik kuralları referansını okuyun.