هيكلة قواعد أمان Cloud Firestore

تسمح لك قواعد أمان Cloud Firestore بالتحكم في الوصول إلى المستندات والمجموعات في قاعدة البيانات الخاصة بك. تسمح لك بنية القواعد المرنة بإنشاء قواعد تطابق أي شيء ، من جميع عمليات الكتابة إلى قاعدة البيانات بأكملها إلى العمليات على مستند معين.

يصف هذا الدليل البنية الأساسية وهيكل قواعد الأمان. ادمج بناء الجملة هذا مع شروط قواعد الأمان لإنشاء مجموعات قواعد كاملة.

إعلان الخدمة وقاعدة البيانات

تبدأ قواعد أمان Cloud Firestore دائمًا بالإعلان التالي:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

يحدد إعلان service cloud.firestore القواعد إلى Cloud Firestore ، مما يمنع التعارض بين قواعد أمان Cloud Firestore وقواعد المنتجات الأخرى مثل التخزين السحابي.

يحدّد إعلان match /databases/{database}/documents أن القواعد يجب أن تتطابق مع أي قاعدة بيانات Cloud Firestore في المشروع. في الوقت الحالي ، يحتوي كل مشروع على قاعدة بيانات واحدة فقط مسماة (default) .

قواعد القراءة / الكتابة الأساسية

تتكون القواعد الأساسية من عبارة match تحدد مسار المستند ويسمح بتعبير allow بالتفصيل عند قراءة البيانات المحددة:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

يجب أن تشير جميع بيانات المطابقة إلى المستندات وليس المجموعات. يمكن أن يشير بيان المطابقة إلى مستند معين ، كما هو الحال في match /cities/SF أو استخدام أحرف البدل للإشارة إلى أي مستند في المسار المحدد ، كما هو الحال في match /cities/{city} .

في المثال أعلاه ، تستخدم تعليمة المطابقة بنية حرف البدل {city} . هذا يعني أن القاعدة تنطبق على أي مستند في مجموعة cities ، مثل /cities/SF أو /cities/NYC . عندما يتم تقييم تعبيرات allow في بيان المطابقة ، فإن متغير city سيحل اسم مستند المدينة ، مثل SF أو NYC .

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

في بعض الحالات ، من المفيد تقسيم read write إلى عمليات أكثر دقة. على سبيل المثال ، قد يرغب تطبيقك في فرض شروط مختلفة على إنشاء المستند عن تلك المفروضة على حذف المستند. أو قد ترغب في السماح بقراءة مستند واحد مع رفض الاستعلامات الكبيرة.

يمكن تقسيم قاعدة read إلى get و list ، بينما يمكن تقسيم قاعدة write إلى create update delete :

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

البيانات الهرمية

يتم تنظيم البيانات في Cloud Firestore في مجموعات من المستندات ، وقد يوسع كل مستند التسلسل الهرمي من خلال المجموعات الفرعية. من المهم فهم كيفية تفاعل قواعد الأمان مع البيانات الهرمية.

ضع في اعتبارك الموقف حيث تحتوي كل وثيقة في مجموعة cities على مجموعة فرعية landmarks . تنطبق قواعد الأمان فقط على المسار المطابق ، لذلك لا تنطبق ضوابط الوصول المحددة في مجموعة cities على المجموعة الفرعية landmarks . بدلاً من ذلك ، اكتب قواعد صريحة للتحكم في الوصول إلى المجموعات الفرعية:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        // Explicitly define rules for the 'landmarks' subcollection
        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

عند تضمين عبارات match المتداخلة ، يكون مسار عبارة match الداخلية دائمًا متعلقًا بمسار عبارة match الخارجية. وبالتالي فإن القواعد التالية متكافئة:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}
service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

أحرف البدل العودية

إذا كنت تريد تطبيق القواعد على تسلسل هرمي عميق عشوائيًا ، فاستخدم صيغة حرف البدل العودية ، {name=**} . فمثلا:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

عند استخدام صيغة أحرف البدل العودية ، سيحتوي متغير حرف البدل على مقطع المسار المطابق بالكامل ، حتى إذا كان المستند موجودًا في مجموعة فرعية متداخلة بعمق. على سبيل المثال ، قد تتطابق القواعد المذكورة أعلاه مع مستند موجود في /cities/SF/landmarks/coit_tower ، وستكون قيمة متغير document هي SF/landmarks/coit_tower .

لاحظ ، مع ذلك ، أن سلوك أحرف البدل العودية يعتمد على إصدار القواعد.

النسخة 1

تستخدم قواعد الأمان الإصدار 1 افتراضيًا. في الإصدار 1 ، تتطابق أحرف البدل العودية مع عنصر مسار واحد أو أكثر. لا تتطابق مع مسار فارغ ، لذا match /cities/{city}/{document=**} المستندات في المجموعات الفرعية ولكن ليس في مجموعة cities ، بينما match /cities/{document=**} كلا المستندين في جمع cities والمجموعات الفرعية.

يجب أن تأتي أحرف البدل العودية في نهاية بيان المباراة.

الإصدار 2

في الإصدار 2 من قواعد الأمان ، تطابق أحرف البدل العودية صفرًا أو أكثر من عناصر المسار. match/cities/{city}/{document=**} تتطابق مع المستندات في أي مجموعات فرعية بالإضافة إلى المستندات الموجودة في مجموعة cities .

يجب عليك الاشتراك في الإصدار 2 عن طريق إضافة rules_version = '2'; في الجزء العلوي من قواعد الأمان الخاصة بك:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

يمكن أن يكون لديك حرف بدل متكرر واحد على الأكثر لكل بيان مباراة ، ولكن في الإصدار 2 ، يمكنك وضع حرف البدل هذا في أي مكان في بيان المباراة. فمثلا:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

إذا كنت تستخدم استعلامات مجموعة المجموعة ، فيجب عليك استخدام الإصدار 2 ، راجع تأمين استعلامات مجموعة المجموعة .

تداخل بيانات المباراة

من الممكن أن يتطابق المستند مع أكثر من بيان match . في حالة تطابق تعبيرات allow المتعددة مع طلب ما ، يُسمح بالوصول إذا true أي من الشروط:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

في المثال أعلاه ، سيتم السماح لجميع عمليات القراءة والكتابة في مجموعة cities لأن القاعدة الثانية true دائمًا ، على الرغم من أن القاعدة الأولى false دائمًا.

حدود قواعد الأمان

أثناء العمل مع قواعد الأمان ، لاحظ الحدود التالية:

حد تفاصيل
الحد الأقصى لعدد المكالمات exists() ، get() ، و getAfter() لكل طلب
  • 10 لطلبات وثيقة واحدة وطلبات الاستعلام.
  • 20 للقراءات متعددة المستندات والمعاملات والكتابات المجمعة. ينطبق الحد السابق البالغ 10 أيضًا على كل عملية.

    على سبيل المثال ، تخيل أنك تقوم بإنشاء طلب كتابة مجمّع مع 3 عمليات كتابة وأن قواعد الأمان الخاصة بك تستخدم مكالمتي وصول إلى المستندات للتحقق من صحة كل عملية كتابة. في هذه الحالة ، تستخدم كل عملية كتابة 2 من 10 مكالمات وصول ويستخدم طلب الكتابة المجمّع 6 من أصل 20 مكالمة وصول.

يؤدي تجاوز أي من الحدين إلى خطأ رفض الإذن.

قد يتم تخزين بعض مكالمات الوصول إلى المستندات مؤقتًا ، ولا يتم احتساب المكالمات المخزنة مؤقتًا ضمن الحدود.

أقصى عمق بيان match متداخلة 10
أقصى طول للمسار ، في مقاطع المسار ، مسموح به ضمن مجموعة من عبارات match المتداخلة 100
الحد الأقصى لعدد متغيرات التقاط المسار المسموح بها ضمن مجموعة من عبارات match المتداخلة 20
الحد الأقصى لعمق استدعاء الوظيفة 20
العدد الأقصى لوسائط الدوال 7
العدد الأقصى من let للارتباطات المتغيرة لكل وظيفة 10
الحد الأقصى لعدد استدعاءات الدوال المتكررة أو الدورية 0 (غير مسموح)
تم تقييم الحد الأقصى لعدد التعبيرات لكل طلب 1،000
الحجم الأقصى لمجموعة القواعد يجب أن تلتزم القواعد بحدود حجم:
  • حد 256 كيلوبايت لحجم مصدر نص مجموعة القواعد المنشور من وحدة تحكم Firebase أو من واجهة سطر الأوامر (CLI) باستخدام firebase deploy .
  • حد 250 كيلو بايت لحجم مجموعة القواعد المترجمة والذي ينتج عندما يعالج Firebase المصدر ويجعله نشطًا في النهاية الخلفية.

الخطوات التالية