Ardışık düzen işlemleri için güvenlik kuralları

Pipeline işlemleri zengin bir özellik seti sunsa da kısıtlama karşılanabilirliğini ve güvenliği sağlamak için kurallar motoru yalnızca karşılaştırma (ör. >) ve mantıksal (ör. or) filtreleri tanıyabilir.

Desteklenen filtre ifadeleri

Ardışık düzen işlemlerinin kurallarınızda belirlenen sınırlamalar içinde kalması için sabitlere karşı mantıksal ve karşılaştırma operatörleri kullanması gerekir. Aşağıdaki filtre türleri, kurallar motoru tarafından tanınır:

  • Karşılaştırmalar: eq, neq, gt, gte, lt, lte, in, arrayContains.
  • Mantıksal: and, or.

Aşağıda bazı örnekler verilmiştir:

  • where(eq("foo", 2))
  • where(lt("foo", 2))
  • documents("/user/1", "/user/2").where(...)

İstek Özellikleri

Kimlik doğrulama ve sorgu bağlamını doğrulamak için request nesnesini kullanmaya devam edebilirsiniz. Ancak standart sorgularda bulunan bazı özellikler, Pipeline işlemlerinde desteklenmez.

Desteklenen tesisler

Yeni motor aşağıdaki özellikleri desteklemeye devam etmektedir:

  • request.auth: Kullanıcı UID'sine ve jeton verilerine erişin.
  • request.method: İşlemi tanımlar (örneğin, get, list).
  • request.path: Erişilen kaynağın yolu.
  • request.time: İsteğin sunucu tarafı zaman damgası.

Desteklenmeyen özellikler

Çok kademeli sorgularda bu değerlerin belirlenmesinin karmaşıklığı nedeniyle limit, offset ve orderBy gibi request.query özellikleri, ardışık düzen işlemleri kuralı kontrollerinde desteklenmez.

Ardışık düzen aşaması işleme ve izinleri

Güvenlik kurallarında belirli ayrıntılı işlemlere karşılık gelen farklı işlem hattı aşamaları vardır:

  • allow list izinleri: collection(), collectionGroup() ve database() aşamaları tarafından tetiklenir.
  • allow get izinleri: get toplu işlemiyle benzer şekilde ele alınan documents() aşaması tarafından tetiklenir.
  • Değişmezler aşaması: literals() aşaması, veritabanından okuma yapmaz ancak maliyetlere neden olabilir. Kötüye kullanımı önlemek için, kurallar tarafından doğrulanabilen başka bir aşamayla (ör. collection()) eşleştirilmesi gerekir.

Alan değişikliği aşamaları

Kurallar yalnızca depolanan veriler üzerinde çalışır ve türetilmiş değerler üzerinde çalışmaz. Bir ardışık düzen, alanları değiştiren aşamalar (ör. add_fields(...), replace_with(...), select(...), remove_fields(...)) içeriyorsa Kural motoru, bu aşama karşılaşıldıktan sonra filtre kısıtlamalarını uygulamayı durdurur. Kuralların beklendiği gibi çalıştığından emin olmak için filtre aşamalarınızı (ör. where) depolanan orijinal belgeleri değiştirebilecek aşamalardan önce yerleştirin.

Örneğin, aşağıdaki güvenlik kuralını ele alalım:

match /databases/{database}/documents {
  match /cities/{city} {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    allow read: if resource.data.visibility == 'public';
  }
}

Reddedildi: Bu kural, addFields aşaması visibility değerinin public olduğu dokümanlar için filtrelemeden önce gerçekleştiğinden aşağıdaki ardışık düzeni reddeder:

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

İzin verilir: Bu kural, where(eq(field("visibility"), constant("public"))) aşaması herhangi bir değişiklik aşamasından önce gerçekleştiği için aşağıdaki ardışık düzene izin verir:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();