Güvenlik Kuralları'nın işleyiş şekli

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ı kimliği) ve yetkilendirmeyi (kullanıcı ne yapabilir?) yöneten bir sunucu oluşturup çalıştırması gerekir.

Firebase Security Rules orta (sunucu) katmanını kaldırır ve verilerinize doğrudan bağlanan istemciler için yola dayalı izinler belirtmenize olanak tanır. Kurallar'ın gelen isteklere 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.

Cloud Firestore

Temel yapı

Cloud Firestore ve Cloud Storage içindeki Firebase Security Rules, aşağıdaki yapıyı ve söz dizimini 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 ifadesi içinde ç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ık yöntemleri, belirtilen veritabanında veya depolama yolunda geniş kapsamlı okuma ve yazma erişimi sağlar.
  • Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
  • Kural: Doğru olarak değerlendirilirse bir isteğe izin veren bir koşul içeren allow ifadesi.

Güvenlik kuralları 2. sürüm

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

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

Eşleşen yollar

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.

Eşleşen alt koleksiyonlar

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

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.

Cloud Storage

Temel yapı

Cloud Firestore ve Cloud Storage içindeki Firebase Security Rules, aşağıdaki yapıyı ve söz dizimini 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 ifadesi içinde ç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ık yöntemleri, belirtilen veritabanında veya depolama yolunda geniş kapsamlı okuma ve yazma erişimi sağlar.
  • Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
  • Kural: Doğru olarak değerlendirilirse bir isteğe izin veren bir koşul içeren allow ifadesi.

Eşleşen yollar

Cloud Storage Security Rules match Cloud Storage içindeki dosyalara erişmek için kullanılan dosya yolları. Kurallar match tam yollar veya joker karakterli yollar olabilir ve kurallar iç içe yerleştirilebilir. Hiçbir eşleşme kuralı bir istek yöntemine izin vermiyorsa veya koşul false olarak değerlendiriliyorsa istek reddedilir.

Tam eşlemeler

// 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 yerleştirilmiş 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 kullanarak bir kalıbı match etmek için de kullanılabilir. Joker karakter, profilePhoto.png gibi tek bir dizeyi veya images/profilePhoto.png gibi birden fazla yol segmentini temsil eden adlandırılmış bir değişkendir.

Joker karakter, joker karakter adının etrafına köşeli parantez ekleyerek oluşturulur (ör. {string}). Joker karakter adına =** ekleyerek birden fazla segment joker karakteri belirtilebilir (ör. {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>;
  }
}

Birden fazla kural bir dosyayla eşleşirse sonuç, tüm kural değerlendirmelerinin sonucunun OR'sidir. Yani, dosyanın eşleştiği bir kural true olarak değerlendirilirse sonuç true olur.

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

Joker değişkenine, match dosya adı veya yol yetkilendirmesi içinden referans verilebilir:

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

Cloud Storage Security Rules basamaklandırılmaz ve kurallar yalnızca istek yolu, belirtilen kurallara sahip bir yola eşleştiğinde değerlendirilir.

Değerlendirme isteğinde bulunma

Yüklemeler, indirmeler, meta veri değişiklikleri ve silme işlemleri, Cloud Storage adresine 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 işlemiyse yeni resource değerini içerir. HTTP başlıkları ve kimlik doğrulama durumu da dahildir.

request nesnesi, kullanıcının benzersiz kimliğini ve request.auth nesnesinde Firebase Authentication yükü de içerir. Bu konu, dokümanların Kimlik Doğrulaması bölümünde daha ayrıntılı olarak açıklanmıştır.

request nesnesinde bulunan özelliklerin tam listesini aşağıda bulabilirsiniz:

Özellik Tür Açıklama
auth map<string, string> Kullanıcı oturum açtığında uid (kullanıcıya ait benzersiz kimlik) ve token (Firebase Authentication JWT iddialarının haritası) sağlar. Aksi takdirde null olur.
params map<string, string> İsteğin sorgu parametrelerini içeren harita.
path yol İsteğin yapıldığı yolu temsil eden bir path.
resource map<string, string> Yalnızca write isteklerinde bulunan yeni kaynak değeri.
time zaman damgası İsteğin değerlendirildiği sunucu zamanını temsil eden bir zaman damgası.

Kaynak değerlendirmesi

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

Cloud Storage için Firebase Security Rules, resource nesnesinde dosya meta verilerini sağlar. Bu nesne, Cloud Storage nesnesinde gösterilen meta verilerin anahtar/değer çiftlerini içerir. Bu özellikler, veri bütünlüğünü sağlamak için read veya write isteklerinde denetlenebilmektedir.

write isteklerinde (yükleme, meta veri güncelleme ve silme gibi), istek yolunda mevcut olan dosyanın meta verilerini içeren resource nesnesine ek olarak, yazma işlemine izin verilirse yazılacak dosya meta verilerinin bir alt kümesini içeren request.resource nesnesini de kullanabilirsiniz. Veri bütünlüğünü sağlamak veya dosya türü ya da boyut gibi uygulama kısıtlamalarını uygulamak için bu iki değeri kullanabilirsiniz.

resource nesnesinde bulunan özelliklerin tam listesini aşağıda bulabilirsiniz:

Özellik Tür Açıklama
name dize Nesnenin tam adı
bucket dize Bu nesnenin bulunduğu paketin adı.
generation int Bu nesnenin Google Cloud Storage nesnesi nesli.
metageneration int Bu nesnenin Google Cloud Storage meta veri oluşturma işlemi.
size int Nesnenin bayt cinsinden boyutu.
timeCreated zaman damgası Bir nesnenin oluşturulduğu zamanı gösteren zaman damgası.
updated zaman damgası Bir nesnenin en son güncellendiği zamanı gösteren zaman damgası.
md5Hash dize Nesnenin MD5 karma değeri.
crc32c dize Nesnenin crc32c karması.
etag dize Bu nesneyle ilişkili etag.
contentDisposition dize Bu nesneyle ilişkili içerik gönderme.
contentEncoding dize Bu nesneyle ilişkili içerik kodlaması.
contentLanguage dize Bu nesneyle ilişkili içerik dili.
contentType dize Bu nesneyle ilişkili içerik türü.
metadata map<string, string> Geliştirici tarafından belirtilen ek özel meta verilerin anahtar/değer çiftleri.

request.resource, generation, metageneration, etag, timeCreated ve updated hariç 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 Ayrıntılar
İstek başına maksimum firestore.exists() ve firestore.get() çağrısı sayısı

Tek belgeli istekler ve sorgu istekleri için 2.

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

Aynı dokümanlara yapılan erişim çağrıları önbelleğe alınabilir. Önbelleğe alınan çağrılar sınırlamaya dahil edilmez.

Tam Örnek

Tüm bunları bir araya getirerek bir resim 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
     }
   }
 }
}

Realtime Database

Temel yapı

Realtime Database içinde Firebase Security Rules, JSON belgesinde bulunan JavaScript benzeri ifadelerden oluşur.

Şu söz dizimini kullanırlar:

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

Kural üç temel öğeden oluşur:

  • Yol: Veritabanı konumu. Bu, veritabanınızın JSON yapısını yansıtır.
  • İstek: Kuralın erişim izni vermek için kullandığı yöntemlerdir. read ve write kuralları geniş kapsamlı okuma ve yazma erişimi sağlarken validate kuralları, gelen veya mevcut verilere göre erişim izni vermek için ikincil bir doğrulama görevi görür.
  • Durum: Doğru olarak değerlendirilirse isteğe izin veren durum.

Kurallar yollara nasıl uygulanır?

Realtime Database'te Rules atomik olarak uygulanır. Yani daha üst düzey üst öğe düğümlerindeki kurallar, daha ayrıntılı alt öğe düğümlerindeki kuralları geçersiz kılar ve daha derin bir düğümdeki kurallar bir üst öğe yoluna erişim izni veremez. Üst yollardan birine erişim izni verdiyseniz veritabanı yapınızdaki daha derin bir yolda erişim iznini ayrıntılandı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/ değeri true olan bir baz alt öğesi içerdiğinde /bar/ öğesinin okunmasına olanak tanır. Erişim, alt yol tarafından iptal edilemediğinden /foo/bar/ altındaki ".read": false kuralı burada geçerli değildir.

Bu, ilk bakışta sezgisel görünmese de kurallar 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ıya dayalı güvenlik için yararlıdır.

Ancak .validate kuralları basamaklandırılmaz. Yazma işlemine izin verilmesi için tüm doğrulama kurallarının hiyerarşinin tüm seviyelerinde karşılanması gerekir.

Ayrıca, kurallar üst bir yola geri 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 üst konumda okuma işlemi tamamen başarısız olur. Şu yapıyı düşünün:

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

Kuralların atomik olarak değerlendirildiğini anlamadan, /records/ yolunun getirilmesi sonucunda rec1 değerinin döndürüleceği, rec2 değerinin ise döndürülmeyeceği düşünülebilir. 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
});
Objective-C
Not: Bu Firebase ürünü, uygulama klipsi hedefinde kullanılamaz.
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
}];
Swift
Not: Bu Firebase ürünü, uygulama klipsi hedefinde kullanılamaz.
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
  });
});
REST
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 işlem PERMISSION_DENIED hatası oluşturur. Bu kuralı Firebase konsolumuzdaki 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ği için işlem reddedildi. Ancak, isteğimizdeki yolda olmadığı için rec1 kuralının hiçbir zaman değerlendirilmediğini unutmayın. rec1 değerini almak için doğrudan bu değere erişmemiz gerekir:

JavaScript
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
Objective-C
Not: Bu Firebase ürünü, uygulama klipsi hedefinde kullanılamaz.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
Swift
Not: Bu Firebase ürünü, uygulama klipsi hedefinde kullanılamaz.
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
  }
});
REST
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Konum değişkeni

Realtime Database Rules, yol segmentlerini eşleştirmek için $location değişkenini destekler. Kuralınızı yol boyuncaki herhangi bir alt düğümle eşleştirmek için yol segmentinizin önüne $ ön ekini ekleyin.

  {
    "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')"
          }
        }
      }
    }
  }

Sabit yol adlarıyla paralel olarak $variable simgesini de 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 }
      }
    }
  }