كيف تعمل قواعد الأمان

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

تعمل قواعد أمان Firebase على إزالة الطبقة الوسطى (الخادم) وتسمح لك بتحديد الأذونات المستندة إلى المسار للعملاء الذين يتصلون ببياناتك مباشرةً. استخدم هذا الدليل لمعرفة المزيد حول كيفية تطبيق القواعد على الطلبات الواردة.

حدد منتجًا لمعرفة المزيد حول قواعده.

سحابة فايرستور

تركيب اساسي

تستخدم قواعد أمان Firebase في Cloud Firestore وCloud Storage البنية والتركيب التاليين:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

من المهم فهم المفاهيم الأساسية التالية أثناء إنشاء القواعد:

  • الطلب: الطريقة أو الأساليب التي تم استدعاؤها في بيان allow . هذه هي الأساليب التي تسمح بتشغيلها. الطرق القياسية هي: get list create update delete . تتيح أساليب read write الملائمة وصولاً واسع النطاق للقراءة والكتابة على قاعدة البيانات المحددة أو مسار التخزين.
  • المسار: قاعدة البيانات أو موقع التخزين، الذي يتم تمثيله كمسار URI.
  • القاعدة: عبارة allow ، التي تتضمن شرطًا يسمح بالطلب إذا تم تقييمه على أنه صحيح.

قواعد الأمان الإصدار 2

اعتبارًا من مايو 2019، أصبح الإصدار 2 من قواعد أمان Firebase متاحًا الآن. يغير الإصدار 2 من القواعد سلوك أحرف البدل العودية {name=**} . يجب عليك استخدام الإصدار 2 إذا كنت تخطط لاستخدام استعلامات مجموعة المجموعة . يجب عليك الاشتراك في الإصدار 2 عن طريق جعل rules_version = '2'; السطر الأول في قواعد الأمان الخاصة بك:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

مسارات متطابقة

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

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

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

يتم تنظيم البيانات الموجودة في 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 بمعالجة المصدر وجعله نشطًا في النهاية الخلفية.

سحابة التخزين

تركيب اساسي

تستخدم قواعد أمان Firebase في Cloud Firestore وCloud Storage البنية والتركيب التاليين:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

من المهم فهم المفاهيم الأساسية التالية أثناء إنشاء القواعد:

  • الطلب: الطريقة أو الأساليب التي تم استدعاؤها في بيان allow . هذه هي الأساليب التي تسمح بتشغيلها. الطرق القياسية هي: get list create update delete . تتيح أساليب read write الملائمة وصولاً واسع النطاق للقراءة والكتابة على قاعدة البيانات المحددة أو مسار التخزين.
  • المسار: قاعدة البيانات أو موقع التخزين، الذي يتم تمثيله كمسار URI.
  • القاعدة: عبارة allow ، التي تتضمن شرطًا يسمح بالطلب إذا تم تقييمه على أنه صحيح.

مسارات متطابقة

match قواعد أمان التخزين السحابي مع مسارات الملفات المستخدمة للوصول إلى الملفات الموجودة في التخزين السحابي. يمكن match القواعد مع المسارات الدقيقة أو مسارات أحرف البدل، ويمكن أيضًا أن تكون القواعد متداخلة. إذا لم تسمح أي قاعدة مطابقة بطريقة طلب، أو إذا تم تقييم الحالة إلى false ، فسيتم رفض الطلب.

التطابقات الدقيقة

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

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

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

مباريات البدل

يمكن أيضًا استخدام القواعد match النمط باستخدام أحرف البدل. حرف البدل هو متغير مسمى يمثل إما سلسلة واحدة مثل profilePhoto.png ، أو أجزاء مسار متعددة، مثل images/profilePhoto.png .

يتم إنشاء حرف البدل عن طريق إضافة أقواس متعرجة حول اسم حرف البدل، مثل {string} . يمكن الإعلان عن حرف بدل متعدد المقاطع عن طريق إضافة =** إلى اسم حرف البدل، مثل {path=**} :

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

إذا تطابقت قواعد متعددة مع ملف ما، فإن النتيجة هي OR نتيجة جميع تقييمات القواعد. أي أنه إذا تم تقييم أي قاعدة يطابقها الملف إلى true ، فإن النتيجة تكون true .

في القواعد المذكورة أعلاه، يمكن قراءة الملف "images/profilePhoto.png" إذا تم تقييم أي من condition أو other_condition على أنها صحيحة، في حين أن الملف "images/users/user:12345/profilePhoto.png" يخضع فقط لنتيجة other_condition .

يمكن الإشارة إلى متغير بدل من داخل match التي توفر اسم الملف أو ترخيص المسار:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

لا تتتالي قواعد أمان التخزين السحابي، ويتم تقييم القواعد فقط عندما يتطابق مسار الطلب مع مسار بقواعد محددة.

طلب التقييم

يتم تقييم عمليات التحميل والتنزيلات وتغييرات البيانات التعريفية والحذف باستخدام request المرسل إلى Cloud Storage. يحتوي متغير request على مسار الملف حيث يتم تنفيذ الطلب، والوقت الذي يتم فيه استلام الطلب، وقيمة resource الجديدة إذا كان الطلب كتابة. يتم أيضًا تضمين رؤوس HTTP وحالة المصادقة.

يحتوي كائن request أيضًا على المعرف الفريد للمستخدم وحمولة مصادقة Firebase في كائن request.auth ، والذي سيتم شرحه بشكل أكبر في قسم المصادقة في المستندات.

تتوفر قائمة كاملة بالخصائص الموجودة في كائن request أدناه:

ملكية يكتب وصف
auth خريطة <سلسلة، سلسلة> عندما يقوم مستخدم بتسجيل الدخول، يتم توفير uid والمعرف الفريد للمستخدم والرمز المميز token مطالبات Firebase Authentication JWT. وإلا فإنه سيكون null .
params خريطة <سلسلة، سلسلة> خريطة تحتوي على معلمات الاستعلام الخاصة بالطلب.
path طريق path يمثل المسار الذي يتم تنفيذ الطلب فيه.
resource خريطة <سلسلة، سلسلة> قيمة المورد الجديدة، موجودة فقط في طلبات write .
time الطابع الزمني طابع زمني يمثل وقت الخادم الذي يتم فيه تقييم الطلب.

تقييم الموارد

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

توفر قواعد أمان Firebase للتخزين السحابي بيانات تعريف الملف في كائن resource ، والذي يحتوي على أزواج المفاتيح/القيمة للبيانات التعريفية التي تظهر في كائن التخزين السحابي. يمكن فحص هذه الخصائص عند طلبات read أو write لضمان سلامة البيانات.

في طلبات write (مثل التحميلات وتحديثات بيانات التعريف والحذف)، بالإضافة إلى كائن resource ، الذي يحتوي على بيانات تعريف الملف للملف الموجود حاليًا في مسار الطلب، لديك أيضًا القدرة على استخدام كائن request.resource ، الذي يحتوي على مجموعة فرعية من البيانات التعريفية للملف المراد كتابتها إذا سمح بالكتابة. يمكنك استخدام هاتين القيمتين لضمان تكامل البيانات أو فرض قيود التطبيق مثل نوع الملف أو حجمه.

تتوفر قائمة كاملة بالخصائص الموجودة في كائن resource أدناه:

ملكية يكتب وصف
name خيط الاسم الكامل للكائن
bucket خيط اسم الدلو الذي يوجد فيه هذا الكائن.
generation كثافة العمليات إنشاء كائن Google Cloud Storage لهذا الكائن.
metageneration كثافة العمليات إنشاء كائن Google Cloud Storage لهذا الكائن.
size كثافة العمليات حجم الكائن بالبايت.
timeCreated الطابع الزمني طابع زمني يمثل الوقت الذي تم فيه إنشاء الكائن.
updated الطابع الزمني طابع زمني يمثل الوقت الذي تم فيه آخر تحديث للكائن.
md5Hash خيط تجزئة MD5 للكائن.
crc32c خيط تجزئة crc32c للكائن.
etag خيط العلامة المرتبطة بهذا الكائن.
contentDisposition خيط التصرف في المحتوى المرتبط بهذا الكائن.
contentEncoding خيط ترميز المحتوى المرتبط بهذا الكائن.
contentLanguage خيط لغة المحتوى المرتبطة بهذا الكائن.
contentType خيط نوع المحتوى المرتبط بهذا الكائن.
metadata خريطة <سلسلة، سلسلة> أزواج المفاتيح/القيمات من البيانات التعريفية المخصصة الإضافية التي حددها المطور.

يحتوي request.resource على كل هذه العناصر باستثناء generation metageneration و etag و timeCreated updated .

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

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

حد تفاصيل
الحد الأقصى لعدد استدعاءات firestore.exists() و firestore.get() لكل طلب

2 لطلبات المستند الواحد وطلبات الاستعلام.

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

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

مثال كامل

بتجميع كل ذلك معًا، يمكنك إنشاء مثال كامل لقواعد حل تخزين الصور:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

قاعدة بيانات الوقت الحقيقي

تركيب اساسي

في قاعدة بيانات Realtime، تتكون قواعد أمان Firebase من تعبيرات تشبه JavaScript موجودة في مستند JSON.

يستخدمون بناء الجملة التالي:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

هناك ثلاثة عناصر أساسية في القاعدة:

  • المسار: موقع قاعدة البيانات. وهذا يعكس بنية JSON الخاصة بقاعدة بياناتك.
  • الطلب: هذه هي الطرق التي تستخدمها القاعدة لمنح حق الوصول. تمنح قواعد read write وصولاً واسع النطاق للقراءة والكتابة، بينما تعمل قواعد validate كتحقق ثانوي لمنح الوصول استنادًا إلى البيانات الواردة أو الموجودة.
  • الشرط: الشرط الذي يسمح بالطلب إذا تم تقييمه على أنه صحيح.

كيفية تطبيق القواعد على المسارات

في Realtime Database، يتم تطبيق القواعد بشكل ذري، مما يعني أن القواعد الموجودة في العقد الأصلية ذات المستوى الأعلى تتجاوز القواعد الموجودة في العقد الفرعية الأكثر دقة والقواعد الموجودة في العقدة الأعمق لا يمكنها منح الوصول إلى المسار الأصلي. لا يمكنك تحسين أو إلغاء الوصول إلى مسار أعمق في بنية قاعدة البيانات الخاصة بك إذا كنت قد منحته بالفعل لأحد المسارات الأصلية.

خذ بعين الاعتبار القواعد التالية:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

تسمح بنية الأمان هذه بقراءة /bar/ عندما يحتوي /foo/ على baz فرعي بقيمة true . ".read": false ضمن /foo/bar/ ليس لها أي تأثير هنا، حيث لا يمكن إلغاء الوصول بواسطة مسار فرعي.

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

ومع ذلك، لا تتالي قواعد .validate . يجب استيفاء جميع قواعد التحقق من الصحة على جميع مستويات التسلسل الهرمي حتى يُسمح بالكتابة.

بالإضافة إلى ذلك، نظرًا لأن القواعد لا تنطبق مرة أخرى على المسار الأصلي، فستفشل عملية القراءة أو الكتابة إذا لم تكن هناك قاعدة في الموقع المطلوب أو في موقع أصل يمنح الوصول. حتى إذا كان من الممكن الوصول إلى كل مسار فرعي متأثر، فستفشل القراءة في الموقع الأصلي تمامًا. النظر في هذا الهيكل:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

بدون فهم أن القواعد يتم تقييمها ذريًا، قد يبدو أن جلب المسار /records/ سيؤدي إلى إرجاع rec1 ولكن ليس rec2 . لكن النتيجة الفعلية هي خطأ:

جافا سكريبت
var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});
ج موضوعية
ملاحظة: منتج Firebase هذا غير متوفر في هدف App Clip.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];
سويفت
ملاحظة: منتج Firebase هذا غير متوفر في هدف App Clip.
var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})
جافا
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});
استراحة
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

نظرًا لأن عملية القراءة في /records/ ذرية، ولا توجد قاعدة قراءة تمنح الوصول إلى جميع البيانات الموجودة ضمن /records/ ، فسيؤدي ذلك إلى ظهور خطأ PERMISSION_DENIED . إذا قمنا بتقييم هذه القاعدة في محاكي الأمان في وحدة تحكم Firebase الخاصة بنا، فيمكننا أن نرى أنه تم رفض عملية القراءة:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

تم رفض العملية لأنه لا توجد قاعدة قراءة تسمح بالوصول إلى المسار /records/ ، لكن لاحظ أنه لم يتم تقييم قاعدةريك rec1 لأنها لم تكن في المسار الذي طلبناه. لجلبريك rec1 ، سنحتاج إلى الوصول إليه مباشرةً:

جافا سكريبت
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
ج موضوعية
ملاحظة: منتج Firebase هذا غير متوفر في هدف App Clip.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
سويفت
ملاحظة: منتج Firebase هذا غير متوفر في هدف App Clip.
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})
جافا
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});
استراحة
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

متغير الموقع

تدعم قواعد قاعدة بيانات الوقت الفعلي متغير $location لمطابقة مقاطع المسار. استخدم البادئة $ أمام مقطع المسار الخاص بك لمطابقة القاعدة الخاصة بك مع أي عقد فرعية على طول المسار.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

يمكنك أيضًا استخدام $variable بالتوازي مع أسماء المسارات الثابتة.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }