يمكن أن يكون الأمان أحد أكثر الأجزاء تعقيدًا في أحجية تطوير التطبيق. في معظم التطبيقات ، يجب على المطورين إنشاء وتشغيل خادم يتعامل مع المصادقة (من هو المستخدم) والتفويض (ما يمكن للمستخدم القيام به).
تقوم قواعد أمان Firebase بإزالة الطبقة الوسطى (الخادم) وتسمح لك بتحديد أذونات تستند إلى المسار للعملاء الذين يتصلون ببياناتك مباشرةً. استخدم هذا الدليل لمعرفة المزيد حول كيفية تطبيق القواعد على الطلبات الواردة.
حدد منتجًا لمعرفة المزيد عن قواعده.
سحابة Firestore
تركيب اساسي
تستخدم قواعد أمان 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() لكل طلب |
يؤدي تجاوز أي من الحدين إلى خطأ رفض الإذن. قد يتم تخزين بعض مكالمات الوصول إلى المستندات مؤقتًا ، ولا يتم احتساب المكالمات المخزنة مؤقتًا ضمن الحدود. |
أقصى عمق بيان match متداخلة | 10 |
أقصى طول للمسار ، في مقاطع المسار ، مسموح به ضمن مجموعة من عبارات match المتداخلة | 100 |
الحد الأقصى لعدد متغيرات التقاط المسار المسموح بها ضمن مجموعة من عبارات match المتداخلة | 20 |
الحد الأقصى لعمق استدعاء الوظيفة | 20 |
العدد الأقصى لوسائط الدوال | 7 |
الحد الأقصى لعدد الروابط let المتغيرة لكل وظيفة | 10 |
الحد الأقصى لعدد استدعاءات الدوال المتكررة أو الدورية | 0 (غير مسموح به) |
تم تقييم الحد الأقصى لعدد التعبيرات لكل طلب | 1،000 |
الحجم الأقصى لمجموعة القواعد | يجب أن تلتزم القواعد بحدود حجم:
|
سحابة التخزين
تركيب اساسي
تستخدم قواعد أمان 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 | int | إنشاء كائن Google Cloud Storage لهذا الكائن. |
metageneration | int | كائن Google Cloud Storage metageneration لهذا الكائن. |
size | int | حجم الكائن بالبايت. |
timeCreated | الطابع الزمني | طابع زمني يمثل الوقت الذي تم فيه إنشاء كائن. |
updated | الطابع الزمني | طابع زمني يمثل وقت آخر تحديث للعنصر. |
md5Hash | خيط | تجزئة MD5 للكائن. |
crc32c | خيط | تجزئة crc32c للكائن. |
etag | خيط | 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 من تعبيرات شبيهة بجافا سكريبت مضمنة في مستند 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 });
ج موضوعية
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 }];
سويفت
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 });
ج موضوعية
FIRDatabaseReference *ref = [[FIRDatabase database] reference]; [[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) { // SUCCESS! }];
سويفت
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 }
}
}
}