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

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

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

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

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

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

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

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 का उपयोग करना होगा। आपको 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 को हल कर देगा।

मिलान उपसंग्रह

क्लाउड फायरस्टोर में डेटा को दस्तावेज़ों के संग्रह में व्यवस्थित किया गया है, और प्रत्येक दस्तावेज़ उपसंग्रह के माध्यम से पदानुक्रम का विस्तार कर सकता है। यह समझना महत्वपूर्ण है कि सुरक्षा नियम पदानुक्रमित डेटा के साथ कैसे इंटरैक्ट करते हैं।

उस स्थिति पर विचार करें जहां 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 संग्रह में दस्तावेज़ों से मेल खाता है।

आपको 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 हो।

सुरक्षा नियम सीमाएँ

जब आप सुरक्षा नियमों के साथ काम करते हैं, तो निम्नलिखित सीमाओं पर ध्यान दें:

आप LIMIT विवरण
प्रति अनुरोध 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 deploy उपयोग करके सीएलआई से प्रकाशित नियम-सेट टेक्स्ट स्रोत के आकार पर 256 केबी की सीमा।
  • संकलित नियम-सेट के आकार पर 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 है। अर्थात्, यदि फ़ाइल का कोई भी नियम 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 उपयोग करके अपलोड, डाउनलोड, मेटाडेटा परिवर्तन और डिलीट का मूल्यांकन किया जाता है। request चर में वह फ़ाइल पथ शामिल होता है जहां अनुरोध किया जा रहा है, वह समय जब अनुरोध प्राप्त होता है, और यदि अनुरोध एक लेखन है तो नया resource मान होता है। HTTP हेडर और प्रमाणीकरण स्थिति भी शामिल हैं।

request ऑब्जेक्ट में request.auth ऑब्जेक्ट में उपयोगकर्ता की विशिष्ट आईडी और फ़ायरबेस प्रमाणीकरण पेलोड भी शामिल है, जिसे दस्तावेज़ों के प्रमाणीकरण अनुभाग में आगे बताया जाएगा।

request ऑब्जेक्ट में संपत्तियों की पूरी सूची नीचे उपलब्ध है:

संपत्ति प्रकार विवरण
auth मानचित्र<स्ट्रिंग, स्ट्रिंग> जब कोई उपयोगकर्ता लॉग इन होता है, तो uid , उपयोगकर्ता की विशिष्ट आईडी और token , फायरबेस प्रमाणीकरण जेडब्ल्यूटी दावों का एक मानचित्र प्रदान करता है। अन्यथा, यह null हो जाएगा.
params मानचित्र<स्ट्रिंग, स्ट्रिंग> मानचित्र जिसमें अनुरोध के क्वेरी पैरामीटर शामिल हैं।
path पथ एक path उस पथ का प्रतिनिधित्व करता है जिस पर अनुरोध निष्पादित किया जा रहा है।
resource मानचित्र<स्ट्रिंग, स्ट्रिंग> नया संसाधन मान, केवल write अनुरोधों पर मौजूद है।
time TIMESTAMP सर्वर समय का प्रतिनिधित्व करने वाला एक टाइमस्टैम्प जिस पर अनुरोध का मूल्यांकन किया जाता है।

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

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

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

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

resource ऑब्जेक्ट में गुणों की पूरी सूची नीचे उपलब्ध है:

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

request.resource generation , metageneration , etag , timeCreated और updated को छोड़कर ये सभी शामिल हैं।

सुरक्षा नियम सीमाएँ

जब आप सुरक्षा नियमों के साथ काम करते हैं, तो निम्नलिखित सीमाओं पर ध्यान दें:

आप LIMIT विवरण
प्रति अनुरोध 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
     }
   }
 }
}

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

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

रीयलटाइम डेटाबेस में, फ़ायरबेस सुरक्षा नियमों में JSON दस्तावेज़ में निहित जावास्क्रिप्ट-जैसी अभिव्यक्तियाँ शामिल होती हैं।

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

{
  "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/ में true मान वाला कोई चाइल्ड baz होता है। /foo/bar/ के अंतर्गत ".read": false नियम का यहां कोई प्रभाव नहीं है, क्योंकि चाइल्ड पथ द्वारा पहुंच को रद्द नहीं किया जा सकता है।

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

हालाँकि, .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 त्रुटि उत्पन्न होगी। यदि हम अपने फायरबेस कंसोल में सुरक्षा सिम्युलेटर में इस नियम का मूल्यांकन करते हैं, तो हम देख सकते हैं कि रीड ऑपरेशन अस्वीकार कर दिया गया था:

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