الهدف الأساسي من إتاحة قواعد طلبات البحث في Pipeline هو توفير إمكانات الفلترة نفسها المتوفّرة في محرك القواعد الحالي. على الرغم من أنّ طلبات البحث في Pipeline توفّر مجموعة كبيرة من الميزات، إلا أنّ محرك القواعد يقتصر على التعرّف على الفلاتر البسيطة لضمان إمكانية تنفيذ طلب البحث وأمانه.
تعبيرات الفلاتر المتوافقة
لكي يتم تقييد طلب بحث بقواعدك، يجب أن يستخدم عوامل تشغيل مقارنة عادية مع ثوابت. تتعرّف "قواعد المحرّك" على أنواع الفلاتر التالية:
- المساواة وعدم المساواة:
eq،neq - المقارنات:
gtوgteوltوlte - العضوية:
in،arrayContains
وإليك بعض الأمثلة:
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، مع عمليات التحقّق من قواعد Pipelines بسبب صعوبة تحديد هذه القيم في طلبات البحث المتعددة المراحل.
التعامل مع مراحل خط سير العمل والأذونات
هناك مراحل مختلفة في مسار المعالجة يتم ربطها بعمليات دقيقة محدّدة في قواعد الأمان:
- أذونات
allow list: يتم تفعيلها من خلال مراحلcollection()وcollectionGroup()وdatabase(). - أذونات
allow get: يتم تفعيلها من خلال مرحلةdocuments()، التي يتم التعامل معها بشكل مشابه لعمليةgetمجمّعة. - مراحل تعديل الحقول: لا تعمل القواعد إلا على البيانات المخزّنة وليس على القيم المشتقة. إذا كان مسار المعالجة يتضمّن مراحل تعدّل الحقول (مثل
AddFieldsوReplaceWithوSelect)، يتوقّف محرّك القواعد عن تطبيق قيود الفلتر بعد مواجهة تلك المرحلة. - مرحلة القيم الحرفية: لا تقرأ مرحلة
literals()من قاعدة البيانات، ولكن قد تتكبّد تكاليف. لمنع إساءة الاستخدام، يجب إقرانها بمرحلة أخرى (مثلcollection()) يمكن التحقّق منها باستخدام القواعد.