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

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

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

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

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

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

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

يحدد إعلان 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 عمليات كتابة وأن قواعد الأمان الخاصة بك تستخدم استدعاءين للوصول إلى المستند للتحقق من صحة كل عملية كتابة. في هذه الحالة، تستخدم كل عملية كتابة اثنتين من مكالمات الوصول العشرة ويستخدم طلب الكتابة المجمع 6 من مكالمات الوصول العشرين الخاصة به.

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

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

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

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