امنیت می تواند یکی از پیچیده ترین قطعات پازل توسعه اپلیکیشن باشد. در اکثر برنامهها، توسعهدهندگان باید سروری بسازند و اجرا کنند که احراز هویت (چه کسی کاربر است) و مجوز (آنچه کاربر میتواند انجام دهد) را مدیریت میکند.
Firebase Security Rules لایه میانی (سرور) را حذف می کند و به شما امکان می دهد مجوزهای مبتنی بر مسیر را برای کلاینت هایی که مستقیماً به داده های شما متصل می شوند مشخص کنید. از این راهنما برای کسب اطلاعات بیشتر در مورد نحوه اعمال قوانین در درخواست های دریافتی استفاده کنید.
یک محصول را انتخاب کنید تا در مورد قوانین آن بیشتر بدانید.
Cloud Firestore
ساختار اساسی
Firebase Security Rules در 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>>
}
}
مفاهیم کلیدی زیر هنگام ایجاد قوانین برای درک مهم هستند:
- Request: متد یا متدهای فراخوانی شده در دستور
allow
. اینها روشهایی هستند که شما به آنها اجازه اجرا می دهید. روش های استاندارد عبارتند از:get
،list
،create
،update
وdelete
. روشهای راحتread
وwrite
، دسترسی گسترده خواندن و نوشتن را در پایگاه داده یا مسیر ذخیرهسازی مشخص شده امکانپذیر میسازد. - Path: پایگاه داده یا محل ذخیره سازی که به عنوان یک مسیر URI نشان داده می شود.
- قانون: عبارت
allow
، که شامل شرطی است که در صورت ارزیابی صحیح، به درخواست اجازه می دهد.
قوانین امنیتی نسخه 2
از ماه می 2019، نسخه 2 قوانین امنیتی Firebase اکنون در دسترس است. نسخه 2 قوانین رفتار حروف عام بازگشتی {name=**}
را تغییر میدهد. اگر قصد استفاده از پرس و جوهای گروه مجموعه را دارید، باید از نسخه 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>;
}
}
}
هنگام استفاده از دستور عام بازگشتی، متغیر wildcard شامل کل بخش مسیر منطبق خواهد بود، حتی اگر سند در یک زیر مجموعه عمیق تو در تو قرار داشته باشد. برای مثال، قوانین فهرست شده در بالا با سندی مطابقت دارد که در /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
مطابقت دارد.
شما باید با افزودن 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 (مجاز نیست) |
حداکثر تعداد عبارات ارزیابی شده در هر درخواست | 1000 |
حداکثر اندازه یک مجموعه قوانین | مجموعه قوانین باید از دو محدودیت اندازه تبعیت کند:
|
Cloud Storage
ساختار اساسی
Firebase Security Rules در 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>>
}
}
مفاهیم کلیدی زیر هنگام ایجاد قوانین برای درک مهم هستند:
- Request: متد یا متدهای فراخوانی شده در دستور
allow
. اینها روشهایی هستند که شما به آنها اجازه اجرا می دهید. روش های استاندارد عبارتند از:get
،list
،create
،update
وdelete
. روشهای راحتread
وwrite
، دسترسی گسترده خواندن و نوشتن را در پایگاه داده یا مسیر ذخیرهسازی مشخص شده امکانپذیر میسازد. - Path: پایگاه داده یا محل ذخیره سازی که به عنوان یک مسیر URI نشان داده می شود.
- قانون: عبارت
allow
، که شامل شرطی است که در صورت ارزیابی صحیح، به درخواست اجازه می دهد.
مسیرهای منطبق
Cloud Storage Security Rules با مسیرهای فایل مورد استفاده برای دسترسی به فایلها در Cloud Storage 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
است. .
یک متغیر wildcard را می توان از داخل match
نام فایل یا مجوز مسیر ارجاع داد:
// Another way to restrict the name of a file match /images/{imageId} { allow read: if imageId == "profilePhoto.png"; }
Cloud Storage Security Rules آبشاری نمی شوند و قوانین تنها زمانی ارزیابی می شوند که مسیر درخواست با مسیری با قوانین مشخص شده مطابقت داشته باشد.
درخواست ارزیابی
بارگذاریها، بارگیریها، تغییرات فراداده، و حذفها با استفاده از request
ارسال شده به Cloud Storage ارزیابی میشوند. متغیر request
شامل مسیر فایلی است که درخواست در آن انجام می شود، زمان دریافت درخواست و مقدار resource
جدید اگر درخواست یک نوشتن باشد. هدرهای HTTP و وضعیت احراز هویت نیز گنجانده شده است.
شی request
همچنین شامل شناسه منحصر به فرد کاربر و بارگذاری Firebase Authentication در شی request.auth
است که در بخش Authentication اسناد توضیح بیشتری داده خواهد شد.
لیست کاملی از خواص در شی request
در زیر موجود است:
اموال | تایپ کنید | توضیحات |
---|---|---|
auth | نقشه<رشته، رشته> | زمانی که کاربر وارد سیستم میشود، uid ، شناسه منحصربهفرد کاربر، و token ، نقشهای از Firebase Authentication JWT را ارائه میکند. در غیر این صورت null خواهد شد. |
params | نقشه<رشته، رشته> | نقشه حاوی پارامترهای پرس و جو درخواست. |
path | مسیر | path نشان دهنده مسیری است که درخواست در آن انجام می شود. |
resource | نقشه<رشته، رشته> | مقدار منبع جدید، فقط در درخواستهای write وجود دارد. |
time | مهر زمانی | یک مهر زمانی که نشان دهنده زمان ارزیابی درخواست سرور است. |
ارزیابی منابع
هنگام ارزیابی قوانین، ممکن است بخواهید فراداده فایل در حال آپلود، دانلود، اصلاح یا حذف را نیز ارزیابی کنید. این به شما امکان میدهد قوانین پیچیده و قدرتمندی ایجاد کنید که کارهایی مانند فقط اجازه میدهد فایلهایی با انواع محتوای خاص آپلود شوند یا فقط فایلهای بزرگتر از اندازه معین حذف شوند.
Firebase Security Rules برای Cloud Storage ابردادههای فایل را در شی resource
ارائه میکند، که شامل جفتهای کلید/مقدار از ابردادههای ظاهر شده در یک شی Cloud Storage است. این ویژگی ها را می توان در درخواست های 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 Database
ساختار اساسی
در Realtime Database ، Firebase Security Rules از عبارات جاوا اسکریپت مانند موجود در یک سند 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 به صورت اتمی اعمال میشوند، به این معنی که قوانین در گرههای والد سطح بالاتر، قوانین را در گرههای فرزند خردتر نادیده میگیرند و قوانین در یک گره عمیقتر نمیتوانند به مسیر والد دسترسی داشته باشند. اگر قبلاً آن را برای یکی از مسیرهای والد اعطا کرده باشید، نمیتوانید دسترسی را در یک مسیر عمیقتر در ساختار پایگاه داده خود اصلاح یا لغو کنید.
قوانین زیر را در نظر بگیرید:
{ "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 });
هدف-C
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 });
هدف-C
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!
متغیر مکان
Rules Realtime Database از یک متغیر $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 }
}
}
}