क्लाउड फायरस्टोर सुरक्षा नियम आपको अपने डेटाबेस में दस्तावेजों और संग्रह तक पहुंच को नियंत्रित करने की अनुमति देते हैं। लचीला नियम सिंटैक्स आपको ऐसे नियम बनाने की अनुमति देता है जो किसी भी चीज़ से मेल खाते हैं, सभी लिखने से लेकर पूरे डेटाबेस तक किसी विशिष्ट दस्तावेज़ पर संचालन के लिए।
यह मार्गदर्शिका सुरक्षा नियमों के मूल सिंटैक्स और संरचना का वर्णन करती है। पूर्ण नियम सेट बनाने के लिए इस सिंटैक्स को सुरक्षा नियमों की शर्तों के साथ संयोजित करें।
सेवा और डेटाबेस घोषणा
क्लाउड फायरस्टार सुरक्षा नियम हमेशा निम्नलिखित घोषणा के साथ शुरू होते हैं:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
क्लाउड फायरस्टोर सुरक्षा नियमों और क्लाउड स्टोरेज जैसे अन्य उत्पादों के नियमों के बीच टकराव को रोकने के लिए service cloud.firestore
घोषणा नियमों को क्लाउड फायरस्टोर तक सीमित करती है।
match /databases/{database}/documents
घोषणा निर्दिष्ट करती है कि नियमों को प्रोजेक्ट में किसी भी क्लाउड फायरस्टोर डेटाबेस से मेल खाना चाहिए। वर्तमान में प्रत्येक प्रोजेक्ट में केवल एक डेटाबेस नाम (default)
।
बुनियादी पढ़ने/लिखने के नियम
मूल नियमों में एक match
विवरण शामिल होता है जो एक दस्तावेज़ पथ निर्दिष्ट करता है और निर्दिष्ट डेटा को पढ़ने की allow
समय अभिव्यक्ति की अनुमति देता है:
service cloud.firestore {
match /databases/{database}/documents {
// Match any document in the 'cities' collection
match /cities/{city} {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
सभी मिलान विवरणों को दस्तावेज़ों की ओर इंगित करना चाहिए, न कि संग्रहों की ओर. एक मैच स्टेटमेंट एक विशिष्ट दस्तावेज़ को इंगित कर सकता है, जैसा कि match /cities/SF
में या निर्दिष्ट पथ में किसी दस्तावेज़ को इंगित करने के लिए वाइल्डकार्ड का उपयोग करें, जैसा कि match /cities/{city}
में है।
उपरोक्त उदाहरण में, मिलान विवरण {city}
वाइल्डकार्ड सिंटैक्स का उपयोग करता है। इसका मतलब है कि नियम cities
के संग्रह में किसी भी दस्तावेज़ पर लागू होता है, जैसे कि /cities/SF
या /cities/NYC
। जब मैच स्टेटमेंट में allow
अभिव्यक्तियों का मूल्यांकन किया जाता है, तो city
चर शहर दस्तावेज़ नाम, जैसे SF
या NYC
के लिए हल हो जाएगा।
दानेदार संचालन
कुछ स्थितियों में, read
और write
को अधिक बारीक संचालन में तोड़ना उपयोगी होता है। उदाहरण के लिए, हो सकता है कि आपका ऐप दस्तावेज़ निर्माण पर दस्तावेज़ हटाने की तुलना में विभिन्न शर्तों को लागू करना चाहे। या हो सकता है कि आप एकल दस्तावेज़ को पढ़ने की अनुमति देना चाहें लेकिन बड़े प्रश्नों को अस्वीकार करना चाहें।
read
रूल को get
और list
में तोड़ा जा सकता है, जबकि write
रूल को create
, update
और delete
में तोड़ा जा सकता है:
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// A write rule can be divided into create, update, and delete rules
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
पदानुक्रमित डेटा
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';
जोड़कर संस्करण 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 |
नियमसेट का अधिकतम आकार | नियम-सेट को दो आकार सीमाओं का पालन करना चाहिए:
|
अगले कदम
- कस्टम सुरक्षा नियम शर्तें लिखें।
- सुरक्षा नियम संदर्भ पढ़ें।