Güvenlik Kuralları nasıl çalışır?

Güvenlik, uygulama geliştirme bulmacasının en karmaşık parçalarından biri olabilir. Çoğu uygulamada, geliştiricilerin kimlik doğrulamayı (kullanıcının kim olduğu) ve yetkilendirmeyi (kullanıcının ne yapabileceğini) yöneten bir sunucu oluşturması ve çalıştırması gerekir.

Firebase Güvenlik Kuralları orta (sunucu) katmanı kaldırır ve verilerinize doğrudan bağlanan istemciler için yol tabanlı izinler belirlemenize olanak tanır. Gelen isteklere kuralların nasıl uygulandığı hakkında daha fazla bilgi edinmek için bu kılavuzu kullanın.

Kuralları hakkında daha fazla bilgi edinmek için bir ürün seçin.

Bulut Firestore

Basit yapı

Cloud Firestore ve Cloud Storage'daki Firebase Güvenlik Kuralları aşağıdaki yapıyı ve sözdizimini kullanır:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Kuralları oluştururken aşağıdaki temel kavramları anlamanız önemlidir:

  • İstek: allow ifadesinde çağrılan yöntem veya yöntemler. Bunlar çalıştırılmasına izin verdiğiniz yöntemlerdir. Standart yöntemler şunlardır: get , list , create , update ve delete . read ve write kolaylığı sağlayan yöntemler, belirtilen veritabanı veya depolama yolunda geniş okuma ve yazma erişimi sağlar.
  • Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
  • Kural: Bir isteğin doğru olarak değerlendirilmesi durumunda izin veren bir koşulu içeren allow ifadesi.

Güvenlik kuralları sürüm 2

Mayıs 2019 itibarıyla Firebase güvenlik kurallarının 2. sürümü kullanıma sunuldu. Kuralların 2. Versiyonu, yinelenen {name=**} joker karakterlerinin davranışını değiştirir. Koleksiyon grubu sorgularını kullanmayı planlıyorsanız sürüm 2'yi kullanmanız gerekir. rules_version = '2'; yaparak sürüm 2'ye dahil olmanız gerekir. güvenlik kurallarınızdaki ilk satır:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Eşleşen yollar

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.

Eşleşen alt koleksiyonlar

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 keyfi olarak derin bir hiyerarşiye uygulanmasını istiyorsanız yinelemeli joker karakter sözdizimini kullanın, {name=**} :

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.

Bulut depolama

Basit yapı

Cloud Firestore ve Cloud Storage'daki Firebase Güvenlik Kuralları aşağıdaki yapıyı ve sözdizimini kullanır:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Kuralları oluştururken aşağıdaki temel kavramları anlamanız önemlidir:

  • İstek: allow ifadesinde çağrılan yöntem veya yöntemler. Bunlar çalıştırılmasına izin verdiğiniz yöntemlerdir. Standart yöntemler şunlardır: get , list , create , update ve delete . read ve write kolaylığı sağlayan yöntemler, belirtilen veritabanı veya depolama yolunda geniş okuma ve yazma erişimi sağlar.
  • Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
  • Kural: Bir isteğin doğru olarak değerlendirilmesi durumunda izin veren bir koşulu içeren allow ifadesi.

Eşleşen yollar

Cloud Storage Güvenlik Kuralları, Cloud Storage'daki dosyalara erişmek için kullanılan dosya yollarıyla match . Kurallar tam yollarla veya joker karakter yollarıyla match ve kurallar iç içe de yerleştirilebilir. Hiçbir eşleşme kuralı bir istek yöntemine izin vermiyorsa veya koşul false olarak değerlendirilirse istek reddedilir.

Tam eşleşmeler

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

İç içe eşleşmeler

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

Joker karakter eşleşmeleri

Kurallar, joker karakterler kullanılarak bir modeli match için de kullanılabilir. Joker karakter, profilePhoto.png gibi tek bir dizeyi veya images/profilePhoto.png gibi birden fazla yol parçasını temsil eden adlandırılmış bir değişkendir.

Bir joker karakter, joker karakter adının etrafına {string} gibi küme parantezleri eklenerek oluşturulur. Çok bölümlü bir joker karakter, joker karakter adına =** eklenerek bildirilebilir, örneğin {path=**} :

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Bir dosyayla birden çok kural eşleşirse sonuç, tüm kural değerlendirmelerinin sonucunun OR . Yani, dosyanın eşleştiği herhangi bir kural true olarak değerlendirilirse sonuç true olur.

Yukarıdaki kurallarda, "images/profilePhoto.png" dosyası, condition veya other_condition doğru olarak değerlendirilirse okunabilir; "images/users/user:12345/profilePhoto.png" dosyası ise yalnızca other_condition sonucuna tabidir. .

match dosya adını veya yol yetkilendirmesini sağlayarak bir joker karakter değişkenine başvurulabilir:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Bulut Depolama Güvenlik Kuralları basamaklanmaz ve kurallar yalnızca istek yolu belirtilen kurallara sahip bir yolla eşleştiğinde değerlendirilir.

Değerlendirme iste

Yüklemeler, indirmeler, meta veri değişiklikleri ve silme işlemleri, Cloud Storage'a gönderilen request kullanılarak değerlendirilir. request değişkeni, isteğin gerçekleştirildiği dosya yolunu, isteğin alındığı zamanı ve istek bir yazma ise yeni resource değerini içerir. HTTP başlıkları ve kimlik doğrulama durumu da dahildir.

request nesnesi ayrıca request.auth nesnesinde kullanıcının benzersiz kimliğini ve Firebase Kimlik Doğrulama yükünü de içerir; bu, belgelerin Kimlik Doğrulama bölümünde daha ayrıntılı olarak açıklanacaktır.

request nesnesindeki özelliklerin tam listesi aşağıda mevcuttur:

Mülk Tip Tanım
auth harita<dize, dize> Bir kullanıcı oturum açtığında, uid , kullanıcının benzersiz kimliği ve token Firebase Authentication JWT iddialarının bir haritasını sağlar. Aksi halde null olacaktır.
params harita<dize, dize> İsteğin sorgu parametrelerini içeren harita.
path yol İsteğin gerçekleştirildiği yolu temsil eden path .
resource harita<dize, dize> Yalnızca write isteklerinde mevcut olan yeni kaynak değeri.
time zaman damgası İsteğin değerlendirildiği sunucu zamanını temsil eden zaman damgası.

Kaynak değerlendirmesi

Kuralları değerlendirirken karşıya yüklenen, indirilen, değiştirilen veya silinen dosyanın meta verilerini de değerlendirmek isteyebilirsiniz. Bu, yalnızca belirli içerik türlerine sahip dosyaların yüklenmesine izin vermek veya yalnızca belirli bir boyuttan büyük dosyaların silinmesine izin vermek gibi işlemleri yapan karmaşık ve güçlü kurallar oluşturmanıza olanak tanır.

Cloud Storage için Firebase Güvenlik Kuralları, bir Cloud Storage nesnesinde ortaya çıkan meta verilerin anahtar/değer çiftlerini içeren resource nesnesinde dosya meta verileri sağlar. Bu özellikler, veri bütünlüğünü sağlamak için read veya write istekleri üzerine incelenebilir.

write isteklerinde (yüklemeler, meta veri güncellemeleri ve silmeler gibi), istek yolunda o anda mevcut olan dosyanın dosya meta verilerini içeren resource nesnesine ek olarak request.resource nesnesini kullanma olanağına da sahipsiniz. yazmaya izin veriliyorsa yazılacak dosya meta verilerinin bir alt kümesini içerir. Veri bütünlüğünü sağlamak veya dosya türü veya boyutu gibi uygulama kısıtlamalarını uygulamak için bu iki değeri kullanabilirsiniz.

resource nesnesindeki özelliklerin tam listesi aşağıda mevcuttur:

Mülk Tip Tanım
name sicim Nesnenin tam adı
bucket sicim Bu nesnenin bulunduğu paketin adı.
generation int Bu nesnenin Google Cloud Storage nesnesi oluşturma .
metageneration int Bu nesnenin Google Cloud Storage nesne meta üretimi .
size int Bayt cinsinden nesnenin boyutu.
timeCreated zaman damgası Bir nesnenin oluşturulduğu zamanı temsil eden zaman damgası.
updated zaman damgası Bir nesnenin en son güncellendiği zamanı temsil eden zaman damgası.
md5Hash sicim Nesnenin MD5 karması.
crc32c sicim Nesnenin crc32c karması.
etag sicim Bu nesneyle ilişkili etag.
contentDisposition sicim Bu nesneyle ilişkili içerik düzeni.
contentEncoding sicim Bu nesneyle ilişkili içerik kodlaması.
contentLanguage sicim Bu nesneyle ilişkili içerik dili.
contentType sicim Bu nesneyle ilişkili içerik türü.
metadata harita<dize, dize> Geliştirici tarafından belirlenen ek özel meta verilerin anahtar/değer çiftleri.

request.resource generation , metageneration , etag , timeCreated ve updated dışında bunların tümünü içerir.

Güvenlik Kuralları 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 firestore.exists() ve firestore.get() çağrı sayısı

Tek belge istekleri ve sorgu istekleri için 2.

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

Aynı belgelere yapılan erişim aramaları önbelleğe alınabilir ve önbelleğe alınan aramalar limitlere dahil edilmez.

Tam Örnek

Hepsini bir araya getirerek bir görüntü depolama çözümü için kuralların tam bir örneğini oluşturabilirsiniz:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Gerçek Zamanlı Veritabanı

Basit yapı

Gerçek Zamanlı Veritabanında Firebase Güvenlik Kuralları, bir JSON belgesinde yer alan JavaScript benzeri ifadelerden oluşur.

Aşağıdaki sözdizimini kullanırlar:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Kuralda üç temel unsur bulunmaktadır:

  • Yol: Veritabanı konumu. Bu, veritabanınızın JSON yapısını yansıtır.
  • İstek: Bunlar, kuralın erişim izni vermek için kullandığı yöntemlerdir. read ve write kuralları geniş okuma ve yazma erişimi sağlarken validate kuralları, gelen veya mevcut verilere dayalı olarak erişim izni vermek için ikincil bir doğrulama görevi görür.
  • Koşul: Bir isteğin doğru olarak değerlendirilmesi durumunda izin veren koşul.

Kurallar yollara nasıl uygulanır?

Gerçek Zamanlı Veritabanında Kurallar atomik olarak uygulanır; bu, daha yüksek düzeydeki ana düğümlerdeki kuralların daha ayrıntılı alt düğümlerdeki kuralları geçersiz kıldığı ve daha derin bir düğümdeki kuralların bir üst yola erişim izni veremeyeceği anlamına gelir. Üst yollardan biri için zaten izin verdiyseniz, veritabanı yapınızda daha derin bir yoldaki erişimi hassaslaştıramaz veya iptal edemezsiniz.

Aşağıdaki kuralları göz önünde bulundurun:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

Bu güvenlik yapısı /foo/ true değerine sahip bir alt baz içerdiğinde /bar/ dosyasının okunmasına olanak tanır. /foo/bar/ altındaki ".read": false kuralının burada hiçbir etkisi yoktur, çünkü erişim bir alt yol tarafından iptal edilemez.

Hemen sezgisel görünmese de, bu, kural dilinin güçlü bir parçasıdır ve çok karmaşık erişim ayrıcalıklarının minimum çabayla uygulanmasına olanak tanır. Bu özellikle kullanıcı tabanlı güvenlik için kullanışlıdır.

Ancak .validate kuralları basamaklandırılmaz. Bir yazmaya izin verilmesi için hiyerarşinin her düzeyinde tüm doğrulama kurallarının karşılanması gerekir.

Ayrıca, kurallar bir üst yola uygulanmadığından, istenen konumda veya üst konumda erişim izni veren bir kural yoksa okuma veya yazma işlemi başarısız olur. Etkilenen her alt yola erişilebilse bile ana konumda okuma tamamen başarısız olur. Bu yapıyı düşünün:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

Kuralların atomik olarak değerlendirildiğini anlamadan, /records/ yolunun getirilmesi rec1 döndürecek ancak rec2 döndürmeyecek gibi görünebilir. Ancak gerçek sonuç bir hatadır:

JavaScript
var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});
Amaç-C
Not: Bu Firebase ürünü, App Clip hedefinde mevcut değildir.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];
Süratli
Not: Bu Firebase ürünü, App Clip hedefinde mevcut değildir.
var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})
Java
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});
DİNLENMEK
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

/records/ adresindeki okuma işlemi atomik olduğundan ve /records/ altındaki tüm verilere erişim izni veren bir okuma kuralı olmadığından, bu bir PERMISSION_DENIED hatası oluşturacaktır. Bu kuralı Firebase konsolumuzda bulunan güvenlik simülatöründe değerlendirirsek okuma işleminin reddedildiğini görebiliriz:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

Hiçbir okuma kuralı /records/ yoluna erişime izin vermediğinden işlem reddedildi, ancak rec1 kuralının istediğimiz yolda olmaması nedeniyle hiçbir zaman değerlendirilmediğini unutmayın. rec1 getirmek için doğrudan erişmemiz gerekir:

JavaScript
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
Amaç-C
Not: Bu Firebase ürünü, App Clip hedefinde mevcut değildir.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
Süratli
Not: Bu Firebase ürünü, App Clip hedefinde mevcut değildir.
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})
Java
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});
DİNLENMEK
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Konum değişkeni

Gerçek Zamanlı Veritabanı Kuralları, yol bölümlerini eşleştirmek için $location değişkenini destekler. Kuralınızı yol boyunca herhangi bir alt düğümle eşleştirmek için yol bölümünüzün önüne $ önekini kullanın.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

$variable sabit yol adlarıyla paralel olarak da kullanabilirsiniz.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }