قوانین امنیتی برای عملیات خط لوله

در حالی که عملیات Pipeline مجموعه‌ای غنی از ویژگی‌ها را ارائه می‌دهد، موتور Rules محدود به تشخیص فیلترهای مقایسه‌ای (مثلاً > ) و منطقی (مثلاً or ) است تا از برآورده شدن محدودیت‌ها و امنیت اطمینان حاصل شود.

عبارات فیلتر پشتیبانی شده

برای اینکه عملیات Pipeline به مرزهای تعیین‌شده توسط قوانین شما محدود شود، باید از عملگرهای منطقی و مقایسه‌ای در برابر ثابت‌ها استفاده کند. انواع فیلترهای زیر توسط موتور Rules شناخته می‌شوند:

مقایسه‌ها: eq ، neq ، gt ، gte ، lt ، lte ، in ، arrayContains .
منطقی: and ، or .

در اینجا چند مثال آورده شده است:

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

درخواست ملک

شما می‌توانید همچنان از شیء request برای اعتبارسنجی احراز هویت و زمینه پرس‌وجو استفاده کنید، اگرچه برخی از ویژگی‌های موجود در پرس‌وجوهای استاندارد در عملیات Pipeline پشتیبانی نمی‌شوند.

ویژگی‌های پشتیبانی‌شده

موتور جدید همچنان از ویژگی‌های زیر پشتیبانی می‌کند:

request.auth : به شناسه کاربری (uid) و داده‌های توکن (token) دسترسی دارد.
request.method : عملیات را شناسایی می‌کند (برای مثال، get ، list ).
request.path : مسیر منبعی که قرار است به آن دسترسی پیدا شود.
request.time : نشانگر زمانی سمت سرور برای درخواست.

ویژگی‌های پشتیبانی نشده

ویژگی‌های request.query مانند limit ، offset و orderBy به دلیل پیچیدگی تعیین این مقادیر در پرس‌وجوهای چند مرحله‌ای، برای بررسی قوانین عملیات Pipeline پشتیبانی نمی‌شوند.

مدیریت و مجوزهای مرحله خط لوله

مراحل مختلفی در خط لوله وجود دارد که به عملیات جزئی خاص در قوانین امنیتی نگاشت می‌شوند:

allow list : توسط مراحل collection() ، collectionGroup() و database() فعال می‌شود.
allow get مجوزها: توسط مرحله documents() فعال می‌شود که مشابه عملیات get دسته‌ای با آن رفتار می‌شود.
مرحله‌ی لیترال‌ها: مرحله‌ی literals() از پایگاه داده نمی‌خواند اما می‌تواند هزینه‌هایی را متحمل شود. برای جلوگیری از سوءاستفاده، باید با مرحله‌ی دیگری (مانند collection() ) جفت شود که بتوان آن را با قوانین تأیید کرد.

مراحل اصلاح مزرعه

قوانین فقط روی داده‌های ذخیره شده عمل می‌کنند و نه روی مقادیر مشتق شده. اگر یک خط لوله شامل مراحلی باشد که فیلدها را تغییر می‌دهند (برای مثال، add_fields(...) ، replace_with(...) ، select(...) ، remove_fields(...) )، موتور قوانین پس از مواجهه با آن مرحله، اعمال محدودیت‌های فیلتر را متوقف می‌کند. برای اطمینان از اینکه قوانین طبق انتظار کار می‌کنند، مراحل فیلتر خود را (یعنی where ) قبل از هر مرحله‌ای که می‌تواند اسناد ذخیره شده اصلی را تغییر دهد، قرار دهید.

برای مثال، قانون امنیتی زیر را در نظر بگیرید:

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';
  }
}

رد شده : این قانون، خط لوله زیر را رد می‌کند زیرا مرحله addFields قبل از فیلتر کردن اسنادی که visibility public است، رخ می‌دهد:

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();

مجاز : این قانون به خط لوله زیر اجازه می‌دهد زیرا مرحله where(eq(field("visibility"), constant("public"))) قبل از هرگونه مرحله اصلاح رخ می‌دهد:

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