सुरक्षा ऐप विकास पहेली के सबसे जटिल टुकड़ों में से एक हो सकती है। अधिकांश अनुप्रयोगों में, डेवलपर्स को एक सर्वर बनाना और चलाना चाहिए जो प्रमाणीकरण (जो उपयोगकर्ता है) और प्राधिकरण (उपयोगकर्ता क्या कर सकता है) को संभालता है।
फायरबेस सुरक्षा नियम मध्य (सर्वर) परत को हटाते हैं और आपको उन ग्राहकों के लिए पथ-आधारित अनुमतियाँ निर्दिष्ट करने की अनुमति देते हैं जो सीधे आपके डेटा से जुड़ती हैं। आने वाले अनुरोधों पर नियम कैसे लागू होते हैं, इस बारे में अधिक जानने के लिए इस मार्गदर्शिका का उपयोग करें।
किसी उत्पाद के नियमों के बारे में अधिक जानने के लिए उसका चयन करें।
क्लाउड फायरस्टोर
बुनियादी संरचना
क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:
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 से, Firebase सुरक्षा नियमों का वर्शन 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
के लिए हल हो जाएगा।
मिलान उपसंग्रह
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
संग्रह में दस्तावेज़ों से मेल खाता है।
आपको 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() कॉल प्रति अनुरोध |
किसी भी सीमा से अधिक होने पर अनुमति अस्वीकृत त्रुटि होती है। कुछ दस्तावेज़ एक्सेस कॉल्स को कैश किया जा सकता है, और कैश्ड कॉल्स को सीमा में नहीं गिना जाता है। |
अधिकतम नेस्टेड match स्टेटमेंट डेप्थ | 10 |
नेस्टेड match स्टेटमेंट के सेट के भीतर पाथ सेगमेंट में अधिकतम पाथ लेंथ की अनुमति है | 100 |
नेस्टेड match स्टेटमेंट के एक सेट के भीतर पाथ कैप्चर वेरिएबल्स की अधिकतम संख्या की अनुमति है | 20 |
अधिकतम फ़ंक्शन कॉल गहराई | 20 |
फ़ंक्शन तर्कों की अधिकतम संख्या | 7 |
प्रति फंक्शन let वेरिएबल बाइंडिंग की अधिकतम संख्या | 10 |
पुनरावर्ती या चक्रीय फ़ंक्शन कॉल की अधिकतम संख्या | 0 (अनुमति नहीं) |
प्रति अनुरोध मूल्यांकन किए गए भावों की अधिकतम संख्या | 1,000 |
नियमसेट का अधिकतम आकार | नियम-सेट को दो आकार सीमाओं का पालन करना चाहिए:
|
घन संग्रहण
बुनियादी संरचना
क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:
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
उपयोग करके अपलोड, डाउनलोड, मेटाडेटा परिवर्तन और विलोपन का मूल्यांकन किया जाता है। 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
होता है। ".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
त्रुटि फेंक देगा। यदि हम अपने फायरबेस कंसोल में सुरक्षा सिम्युलेटर में इस नियम का मूल्यांकन करते हैं, तो हम देख सकते हैं कि रीड ऑपरेशन अस्वीकार कर दिया गया था:
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 }
}
}
}