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

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

تعبيرات الفلاتر المتاحة

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

• المقارنات: 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 عنصر للتحقّق من عملية المصادقة وسياق طلب البحث، على الرغم من أنّ بعض الخصائص المتاحة في طلبات البحث العادية غير متاحة في عمليات خطوط البيانات.

الخصائص المتاحة

يواصل المحرّك الجديد دعم الخصائص التالية:

• request.auth: للوصول إلى رقم تعريف المستخدم وبيانات الرمز المميّز
• request.method: لتحديد العملية (على سبيل المثال، get أو list)
• request.path: مسار المورد الذي يتم الوصول إليه
• request.time: الطابع الزمني للطلب من جهة الخادم

الخصائص غير المتاحة

لا تتوافق خصائص request.query، مثل limit وoffset وorderBy، مع عمليات التحقّق من قواعد عمليات خطوط البيانات بسبب صعوبة تحديد هذه القيم في طلبات البحث المتعدّدة المراحل.

التعامل مع مراحل خطوط البيانات والأذونات

هناك مراحل مختلفة لخطوط البيانات تتطابق مع عمليات دقيقة معيّنة في قواعد الأمان:

• أذونات 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();