قواعد الأمان لعمليات خطوط الإنتاج

على الرغم من أنّ عمليات Pipeline توفّر مجموعة كبيرة من الميزات، يقتصر محرك القواعد على التعرّف على فلاتر المقارنة (مثل >) والفلاتر المنطقية (مثل or) لضمان إمكانية استيفاء القيود والأمان.

تعبيرات الفلاتر المتوافقة

لكي تقتصر عمليات Pipeline على الحدود التي تحدّدها قواعدك، يجب أن تستخدم عوامل تشغيل منطقية ومقارنة مع الثوابت. تتعرّف "قواعد المحرّك" على أنواع الفلاتر التالية:

• المقارنات: eq وneq وgt وgte وlt وlte وin وarrayContains
• منطقي: and، or.

وإليك بعض الأمثلة:

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

ملاحظة: لا يتم التعرّف على العبارات المعقّدة، مثل العمليات الحسابية ضمن فلتر (على سبيل المثال، where(eq("foo" * 2, 10))) أو دوال السلسلة مثل strContains، عند تقييد طلبات البحث.

سمات الطلب

يمكنك مواصلة استخدام العنصر request للتحقّق من صحة المصادقة وسياق طلب البحث، مع العلم أنّ بعض الخصائص المتاحة في طلبات البحث العادية غير متوافقة مع عمليات Pipeline.

السمات المتوافقة

يواصل المحرّك الجديد إتاحة السمات التالية:

• request.auth: للوصول إلى بيانات الرمز المميّز ومعرّف المستخدم الفريد
• 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();