Catch up on everthing we announced at this year's Firebase Summit. Learn more

सुरक्षा नियम कैसे काम करते हैं

सुरक्षा ऐप डेवलपमेंट पहेली के सबसे जटिल टुकड़ों में से एक हो सकती है। अधिकांश अनुप्रयोगों में, डेवलपर्स को एक सर्वर बनाना और चलाना चाहिए जो प्रमाणीकरण (एक उपयोगकर्ता कौन है) और प्राधिकरण (एक उपयोगकर्ता क्या कर सकता है) को संभालता है।

फायरबेस सुरक्षा नियम मध्य (सर्वर) परत को हटाते हैं और आपको उन क्लाइंट के लिए पथ-आधारित अनुमतियां निर्दिष्ट करने की अनुमति देते हैं जो सीधे आपके डेटा से जुड़ते हैं। आने वाले अनुरोधों पर नियम कैसे लागू होते हैं, इस बारे में अधिक जानने के लिए इस मार्गदर्शिका का उपयोग करें।

किसी उत्पाद के नियमों के बारे में अधिक जानने के लिए उसका चयन करें।

क्लाउड फायरस्टोर

बुनियादी संरचना

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:

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 , और deleteread और write सुविधा तरीकों निर्दिष्ट डेटाबेस या भंडारण पथ पर व्यापक पढ़ने और लिखने के लिए एक्सेस सक्षम करें।
  • पथ: डेटाबेस या भंडारण स्थान, यूआरआई पथ के रूप में प्रतिनिधित्व किया।
  • नियम: allow बयान है, जो एक शर्त है कि एक अनुरोध परमिट अगर यह सही का आकलन भी शामिल है।

सुरक्षा नियम संस्करण 2

मई 2019 तक, फायरबेस सुरक्षा नियमों का संस्करण 2 अब उपलब्ध है। नियमों का संस्करण 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 subcollection। सुरक्षा नियमों, केवल मिलान किया पथ पर लागू होते हैं इतने पर परिभाषित पहुँच नियंत्रण cities संग्रह पर लागू नहीं होते landmarks subcollection। इसके बजाय, उप-संग्रहों तक पहुंच को नियंत्रित करने के लिए स्पष्ट नियम लिखें:

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=**} में subcollections में दस्तावेजों से मेल खाता है, लेकिन नहीं cities संग्रह है, जबकि match /cities/{document=**} में दोनों दस्तावेजों से मेल खाता है cities संग्रह और subcollections।

रिकर्सिव वाइल्डकार्ड मैच स्टेटमेंट के अंत में आने चाहिए।

संस्करण 2

सुरक्षा नियमों के संस्करण 2 में, पुनरावर्ती वाइल्डकार्ड शून्य या अधिक पथ आइटम से मेल खाते हैं। match/cities/{city}/{document=**} में किसी भी subcollections के साथ ही दस्तावेजों में दस्तावेजों से मेल खाता 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 एक्सेस कॉलों में से 2 का उपयोग करता है और बैच लिखने का अनुरोध इसके 20 एक्सेस कॉलों में से 6 का उपयोग करता है।

किसी भी सीमा से अधिक परिणाम एक अनुमति अस्वीकृत त्रुटि में परिणाम देता है।

कुछ दस्तावेज़ एक्सेस कॉल को कैश किया जा सकता है, और कैश्ड कॉल को सीमा में नहीं गिना जाता है।

अधिकतम नेस्टेड match बयान गहराई 10
अधिकतम पथ लंबाई, पथ के सेगमेंट में, नेस्टेड का एक सेट के भीतर अनुमति match बयान 100
पथ पर कब्जा चर की अधिकतम संख्या नेस्टेड का एक सेट के भीतर अनुमति match बयान 20
अधिकतम फ़ंक्शन कॉल गहराई 20
फ़ंक्शन तर्कों की अधिकतम संख्या 7
की अधिकतम संख्या let समारोह प्रति चर बाइंडिंग 10
पुनरावर्ती या चक्रीय फ़ंक्शन कॉल की अधिकतम संख्या 0 (अनुमति नहीं)
प्रति अनुरोध मूल्यांकन किए गए भावों की अधिकतम संख्या 1,000
एक नियम का अधिकतम आकार नियमों को दो आकार सीमाओं का पालन करना चाहिए:
  • Firebase कंसोल से या CLI का उपयोग करने से प्रकाशित नियम-सेट पाठ स्रोत के आकार पर एक 256 केबी सीमा firebase deploy
  • संकलित नियमों के आकार पर 250 केबी की सीमा जिसके परिणामस्वरूप फायरबेस स्रोत को संसाधित करता है और इसे बैक-एंड पर सक्रिय बनाता है।

घन संग्रहण

बुनियादी संरचना

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:

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 , और deleteread और write सुविधा तरीकों निर्दिष्ट डेटाबेस या भंडारण पथ पर व्यापक पढ़ने और लिखने के लिए एक्सेस सक्षम करें।
  • पथ: डेटाबेस या भंडारण स्थान, यूआरआई पथ के रूप में प्रतिनिधित्व किया।
  • नियम: 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 सभी नियमों का मूल्यांकन का परिणाम की। यह है कि, किसी भी नियम है, तो फ़ाइल के लिए evalutes से मेल खाता है true , परिणाम है true

उपरोक्त नियमों में, फ़ाइल "छवियों / profilePhoto.png" यदि या तो पढ़ा जा सकता है condition या other_condition सच का मूल्यांकन है, जबकि फ़ाइल "छवियों / उपयोगकर्ताओं / उपयोगकर्ता: 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 , उपयोगकर्ता के अद्वितीय ID, और token , Firebase प्रमाणीकरण जेडब्ल्यूटी दावों का एक नक्शा। अन्यथा, यह हो जाएगा null
params नक्शा<स्ट्रिंग, स्ट्रिंग> अनुरोध के क्वेरी पैरामीटर युक्त नक्शा।
path पथ एक path पथ अनुरोध पर प्रदर्शन किया जा रहा है का प्रतिनिधित्व।
resource नक्शा<स्ट्रिंग, स्ट्रिंग> नए संसाधन मूल्य, पर केवल पेश write अनुरोध।
time TIMESTAMP सर्वर समय का प्रतिनिधित्व करने वाला एक टाइमस्टैम्प अनुरोध का मूल्यांकन किया जाता है।

संसाधन मूल्यांकन

नियमों का मूल्यांकन करते समय, आप अपलोड, डाउनलोड, संशोधित, या हटाई जा रही फ़ाइल के मेटाडेटा का मूल्यांकन भी कर सकते हैं। यह आपको जटिल और शक्तिशाली नियम बनाने की अनुमति देता है जो केवल कुछ सामग्री प्रकारों वाली फ़ाइलों को अपलोड करने की अनुमति देता है, या केवल एक निश्चित आकार से बड़ी फ़ाइलों को हटाने की अनुमति देता है।

क्लाउड संग्रहण के लिए Firebase सुरक्षा नियमों में फ़ाइल मेटाडेटा प्रदान resource वस्तु है, जो मेटाडाटा के कुंजी / मान जोड़े एक क्लाउड संग्रहण वस्तु में सामने होता है। इन गुणों पर निरीक्षण किया जा सकता है read या write अनुरोध डेटा अखंडता को सुनिश्चित करने।

पर write अनुरोध (जैसे अपलोड, मेटाडाटा अद्यतन, और हटाए गए के रूप में), के अलावा resource वस्तु है, जो फ़ाइल फ़िलहाल मौजूद अनुरोध पथ पर, आप भी का उपयोग करने की क्षमता है के लिए फ़ाइल मेटाडेटा request.resource वस्तु, जिसमें फ़ाइल मेटाडेटा का एक सबसेट होता है जिसे लिखने की अनुमति होने पर लिखा जाना है। आप डेटा अखंडता सुनिश्चित करने या फ़ाइल प्रकार या आकार जैसी एप्लिकेशन बाधाओं को लागू करने के लिए इन दो मानों का उपयोग कर सकते हैं।

में गुण की पूरी सूची resource वस्तु नीचे उपलब्ध है:

संपत्ति प्रकार विवरण
name डोरी वस्तु का पूरा नाम
bucket डोरी यह वस्तु जिस बाल्टी में रहती है उसका नाम।
generation NS Google क्लाउड संग्रहण वस्तु पीढ़ी इस वस्तु की।
metageneration NS Google क्लाउड संग्रहण वस्तु metageneration इस वस्तु की।
size NS वस्तु का आकार बाइट्स में।
timeCreated TIMESTAMP एक टाइमस्टैम्प उस समय का प्रतिनिधित्व करता है जब कोई वस्तु बनाई गई थी।
updated TIMESTAMP एक टाइमस्टैम्प उस समय का प्रतिनिधित्व करता है जब किसी ऑब्जेक्ट को अंतिम बार अपडेट किया गया था।
md5Hash डोरी वस्तु का MD5 हैश।
crc32c डोरी वस्तु का एक crc32c हैश।
etag डोरी इस वस्तु से जुड़ा ईटैग।
contentDisposition डोरी इस वस्तु से संबद्ध सामग्री स्वभाव।
contentEncoding डोरी इस ऑब्जेक्ट से संबद्ध सामग्री एन्कोडिंग।
contentLanguage डोरी इस वस्तु से जुड़ी सामग्री भाषा।
contentType डोरी इस ऑब्जेक्ट से संबद्ध सामग्री प्रकार।
metadata नक्शा<स्ट्रिंग, स्ट्रिंग> अतिरिक्त, डेवलपर द्वारा निर्दिष्ट कस्टम मेटाडेटा के कुंजी/मान जोड़े।

request.resource के अपवाद के साथ इन सभी का होता है generation , metageneration , etag , timeCreated , और updated

पूरा उदाहरण

यह सब एक साथ रखकर, आप छवि संग्रहण समाधान के लिए नियमों का एक पूर्ण उदाहरण बना सकते हैं:

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
     }
   }
 }
}

रीयलटाइम डेटाबेस

बुनियादी संरचना

रीयलटाइम डेटाबेस में, Firebase सुरक्षा नियमों में JSON दस्तावेज़ में मौजूद JavaScript जैसे भाव होते हैं।

वे निम्नलिखित सिंटैक्स का उपयोग करते हैं:

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

नियम में तीन बुनियादी तत्व हैं:

  • पथ: डेटाबेस स्थान। यह आपके डेटाबेस की JSON संरचना को प्रतिबिंबित करता है।
  • अनुरोध: इन विधियों नियम का उपयोग करता है पहुँच प्रदान करने के हैं। read और write के नियम, व्यापक पढ़ने और लिखने के लिए एक्सेस अनुदान जबकि validate नियम भेजे या मौजूदा डेटा के आधार पर अनुदान का उपयोग करने के लिए एक उच्च माध्यमिक सत्यापन के रूप में काम करते हैं।
  • शर्त: शर्त यह है कि एक अनुरोध परमिट अगर यह सही का आकलन।

पथों पर नियम कैसे लागू होते हैं

रीयलटाइम डेटाबेस में, नियम परमाणु रूप से लागू होते हैं, जिसका अर्थ है कि उच्च-स्तरीय पैरेंट नोड्स पर नियम अधिक दानेदार चाइल्ड नोड्स पर नियमों को ओवरराइड करते हैं और गहरे नोड पर नियम पैरेंट पथ तक पहुंच प्रदान नहीं कर सकते हैं। यदि आप इसे पहले से ही मूल पथों में से किसी एक के लिए प्रदान कर चुके हैं तो आप अपने डेटाबेस संरचना में गहरे पथ पर पहुंच को परिशोधित या निरस्त नहीं कर सकते हैं।

निम्नलिखित नियमों पर विचार करें:

{
  "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
      }
    }
  }
}

समझ है कि नियमों atomically मूल्यांकन किया जाता है के बिना, यह प्राप्त करने में कठिनाई की तरह लग सकता है /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 उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
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 उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
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 उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
तीव्र
नोट: यह Firebase उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
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 }
      }
    }
  }