Gerçek Zamanlı Veritabanı Güvenlik Kurallarında kullanım koşulları

Bu kılavuz, Firebase Gerçek Zamanlı Veritabanı Güvenlik Kurallarınıza nasıl koşul ekleyeceğinizi göstermek için temel Firebase Güvenlik Kuralları dilini öğrenin kılavuzunu temel alır.

Gerçek Zamanlı Veritabanı Güvenlik Kurallarının birincil yapı taşı koşuldur . Koşul, belirli bir işleme izin verilip verilmeyeceğini belirleyen bir Boolean ifadesidir. Temel kurallar için, koşul olarak true ve false hazır değerleri kullanmak, mükemmel bir şekilde çalışır. Ancak, Gerçek Zamanlı Veritabanı Güvenlik Kuralları dili, size aşağıdakileri yapabilecek daha karmaşık koşullar yazmanız için yollar sunar:

• Kullanıcı kimlik doğrulamasını kontrol edin
• Mevcut verileri yeni gönderilen verilere göre değerlendirin
• Veritabanınızın farklı bölümlerine erişin ve bunları karşılaştırın
• Gelen verileri doğrula
• Güvenlik mantığı için gelen sorguların yapısını kullanın

Yol Segmentlerini Yakalamak için $ Değişkenlerini Kullanma

Yakalama değişkenlerini $ önekiyle bildirerek okuma veya yazma için yolun bölümlerini yakalayabilirsiniz. Bu, bir joker karakter işlevi görür ve bu anahtarın değerini kural koşulları içinde kullanmak üzere saklar:

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

Dinamik $ değişkenleri, sabit yol adlarıyla paralel olarak da kullanılabilir. Bu örnekte, widget title ve color dışında alt öğesi olmamasını sağlayan bir .validate kuralı bildirmek için $other değişkenini kullanıyoruz. Ek alt öğelerin oluşturulmasına neden olacak herhangi bir yazma işlemi başarısız olur.

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

kimlik doğrulama

En yaygın güvenlik kuralı modellerinden biri, kullanıcının kimlik doğrulama durumuna göre erişimi denetlemektir. Örneğin, uygulamanız yalnızca oturum açmış kullanıcıların veri yazmasına izin vermek isteyebilir.

Uygulamanız Firebase Kimlik Doğrulaması kullanıyorsa request.auth değişkeni, veri isteyen istemci için kimlik doğrulama bilgilerini içerir. request.auth hakkında daha fazla bilgi için başvuru belgelerine bakın.

Firebase Authentication, koşulları kullanarak kullanıcı bazında veri erişimini kontrol etmenize izin vermek için Firebase Gerçek Zamanlı Veritabanı ile entegre olur. Bir kullanıcı kimlik doğrulamasından sonra, Gerçek Zamanlı Veritabanı Güvenlik Kuralları kurallarınızdaki auth değişkeni kullanıcının bilgileriyle doldurulacaktır. Bu bilgiler, benzersiz tanımlayıcılarını ( uid ) ve Facebook kimliği veya e-posta adresi gibi bağlantılı hesap verilerini ve diğer bilgileri içerir. Özel bir kimlik doğrulama sağlayıcısı uygularsanız, kendi alanlarınızı kullanıcınızın kimlik doğrulama yüküne ekleyebilirsiniz.

Bu bölüm, Firebase Gerçek Zamanlı Veritabanı Güvenlik Kuralları dilini, kullanıcılarınız hakkındaki kimlik doğrulama bilgileriyle nasıl birleştireceğinizi açıklamaktadır. Bu iki kavramı birleştirerek, kullanıcı kimliğine dayalı olarak verilere erişimi kontrol edebilirsiniz.

auth Değişkeni

Kurallarda önceden tanımlanmış auth değişkeni, kimlik doğrulama gerçekleşmeden önce boştur.

Bir kullanıcının kimliği Firebase Authentication ile doğrulandıktan sonra, aşağıdaki öznitelikleri içerecektir:

Burada, her kullanıcının yalnızca kullanıcıya özel bir yola yazabilmesini sağlamak için auth değişkenini kullanan örnek bir kural verilmiştir:

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

Veritabanınızı Kimlik Doğrulama Koşullarını Destekleyecek Şekilde Yapılandırma

Veritabanınızı, Kural yazmayı kolaylaştıracak şekilde yapılandırmanız genellikle yararlıdır. Gerçek Zamanlı Veritabanında kullanıcı verilerini depolamak için yaygın bir model, tüm kullanıcılarınızı, çocukları her kullanıcı için uid değerleri olan tek bir users düğümünde depolamaktır. Bu verilere erişimi, yalnızca oturum açmış kullanıcının kendi verilerini görebileceği şekilde kısıtlamak isterseniz, kurallarınız şöyle görünür.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Kimlik Doğrulama Özel Talepleriyle Çalışma

Firebase Authentication, farklı kullanıcılar için özel erişim denetimi gerektiren uygulamalar için, geliştiricilerin bir Firebase kullanıcısı üzerinde hak talepleri belirlemesine olanak tanır. Bu taleplere, kurallarınızdaki auth.token değişkeninde erişilebilir. hasEmergencyTowel özel talebini kullanan kurallara bir örnek:

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

Kendi özel kimlik doğrulama belirteçlerini oluşturan geliştiriciler, isteğe bağlı olarak bu belirteçlere talep ekleyebilir. Bu talepler, kurallarınızdaki auth.token değişkeninde mevcuttur.

Mevcut Veriler ve Yeni Veriler

Önceden tanımlanmış data değişkeni, bir yazma işlemi gerçekleşmeden önce verilere başvurmak için kullanılır. Tersine, newData değişkeni, yazma işlemi başarılı olursa var olacak yeni verileri içerir. newData yazılmakta olan yeni verilerin ve mevcut verilerin birleştirilmiş sonucunu temsil eder.

Örnek olarak, bu kural yeni kayıtlar oluşturmamıza veya mevcut olanları silmemize izin verir, ancak boş olmayan mevcut verilerde değişiklik yapmamıza izin vermez:

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

Diğer Yollardaki Verilere Referans Verme

Kurallar için herhangi bir veri kriter olarak kullanılabilir. Önceden tanımlanmış root , data ve newData değişkenlerini kullanarak, bir yazma olayından önce veya sonra var olan herhangi bir yola erişebiliriz.

/allow_writes/ düğümünün değeri true olduğu, üst düğümün readOnly bayrak kümesi olmadığı ve yeni yazılan verilerde foo adlı bir alt öğe olduğu sürece yazma işlemlerine izin veren bu örneği ele alalım:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Verileri Doğrulama

Veri yapılarını zorunlu kılmak ve verilerin biçimini ve içeriğini doğrulamak, yalnızca bir .write kuralı erişim vermeyi başardıktan sonra çalıştırılan .validate kuralları kullanılarak yapılmalıdır. Aşağıda, yalnızca 1900-2099 yılları arasındaki YYYY-AA-GG biçimindeki tarihlere izin veren ve düzenli bir ifade kullanılarak kontrol edilen örnek bir .validate kuralı tanımı bulunmaktadır.

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

.validate kuralları, kademeli olmayan tek güvenlik kuralı türüdür. Herhangi bir alt kayıtta herhangi bir doğrulama kuralı başarısız olursa, tüm yazma işlemi reddedilecektir. Ek olarak, veriler silindiğinde (yani, yazılan yeni değer null olduğunda) doğrulama tanımları yoksayılır.

Bunlar önemsiz noktalar gibi görünebilir, ancak aslında güçlü Firebase Gerçek Zamanlı Veritabanı Güvenlik Kuralları yazmak için önemli özelliklerdir. Aşağıdaki kuralları göz önünde bulundurun:

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

Bu varyantı göz önünde bulundurarak, aşağıdaki yazma işlemlerinin sonuçlarına bakın:

var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);

FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];

var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Şimdi aynı yapıya bakalım, ancak .validate yerine .write kurallarını kullanalım:

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

Bu varyantta, aşağıdaki işlemlerden herhangi biri başarılı olacaktır:

var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);

Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];

var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)

Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);

# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Bu, .write ve .validate kuralları arasındaki farkları gösterir. Gösterildiği gibi, silme işlemlerine izin verilip verilmeyeceğine bağlı olan newData.hasChildren() kuralı dışında, bu kuralların tümü .validate kullanılarak yazılmalıdır.

Sorgu Tabanlı Kurallar

Kuralları filtre olarak kullanamasanız da, kurallarınızdaki sorgu parametrelerini kullanarak verilerin alt kümelerine erişimi sınırlayabilirsiniz. query. sorgu parametrelerine dayalı olarak okuma veya yazma erişimi vermek için kurallarınızdaki ifadeler.

Örneğin, aşağıdaki sorgu tabanlı kural, baskets koleksiyonundaki verilere erişimi yalnızca etkin kullanıcının sahip olduğu alışveriş sepetleriyle kısıtlamak için kullanıcı tabanlı güvenlik kurallarını ve sorgu tabanlı kuralları kullanır:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

Kuraldaki sorgu parametrelerini içeren aşağıdaki sorgu başarılı olur:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

Ancak, kuraldaki parametreleri içermeyen sorgular bir PermissionDenied hatasıyla başarısız olur:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

Bir istemcinin okuma işlemleri aracılığıyla ne kadar veri indireceğini sınırlamak için sorgu tabanlı kuralları da kullanabilirsiniz.

Örneğin, aşağıdaki kural okuma erişimini önceliğe göre sıralandığı şekilde bir sorgunun yalnızca ilk 1000 sonucuna sınırlar:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

Aşağıdaki query. ifadeler, Gerçek Zamanlı Veritabanı Güvenlik Kurallarında mevcuttur.

Sonraki adımlar

Koşullarla ilgili bu tartışmadan sonra, Kurallar konusunda daha gelişmiş bir anlayışa sahip oldunuz ve şunları yapmaya hazırsınız:

Temel kullanım durumlarını nasıl ele alacağınızı öğrenin ve Kuralları geliştirmek, test etmek ve dağıtmak için iş akışını öğrenin:

• Koşullar oluşturmak için kullanabileceğiniz önceden tanımlanmış Kural değişkenlerinin tamamı hakkında bilgi edinin.
• Yaygın senaryoları ele alan kurallar yazın.
• Güvenli olmayan Kuralları tespit etmeniz ve bunlardan kaçınmanız gereken durumları gözden geçirerek bilginizi geliştirin.
• Firebase Local Emulator Suite ve onu Kuralları test etmek için nasıl kullanabileceğinizi öğrenin.
• Kuralları dağıtmak için kullanılabilecek yöntemleri gözden geçirin.

Realtime Database'e özgü Kuralları Öğrenin özellikleri:

• Gerçek Zamanlı Veritabanınızı nasıl indeksleyeceğinizi öğrenin.
• Kuralları dağıtmak için REST API'sini inceleyin.