Cloud Firestore के सुरक्षा नियमों की मदद से, अपने डेटाबेस में मौजूद दस्तावेज़ों और कलेक्शन के ऐक्सेस को कंट्रोल किया जा सकता है. सुविधाजनक नियमों के सिंटैक्स की मदद से, किसी भी चीज़ से मेल खाने वाले नियम बनाए जा सकते हैं. इनमें, सभी लिखे गए से लेकर पूरे डेटाबेस तक, और किसी खास दस्तावेज़ पर की गई कार्रवाइयां शामिल हैं.
इस गाइड में सुरक्षा के नियमों के बुनियादी सिंटैक्स और स्ट्रक्चर के बारे में बताया गया है. इस सिंटैक्स को सुरक्षा नियम की शर्तों के साथ जोड़कर, पूरे नियम सेट बनाएं.
सेवा और डेटाबेस का एलान करना
Cloud Firestore के सुरक्षा नियम, हमेशा नीचे दिए गए एलान से शुरू होते हैं:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
service cloud.firestore
के एलान में, Cloud Firestore के नियमों को शामिल किया गया है. इससे Cloud Firestore के सुरक्षा नियमों और Cloud Storage जैसे दूसरे प्रॉडक्ट के नियमों के बीच कोई टकराव नहीं होगा.
match /databases/{database}/documents
के एलान से पता चलता है कि नियमों को
प्रोजेक्ट में किसी भी Cloud Firestore डेटाबेस से मेल खाना चाहिए. फ़िलहाल, हर प्रोजेक्ट में (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
कलेक्शन के दस्तावेज़ों से मेल खाता है.
आपको वर्शन 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() कॉल की संख्या |
सीमा से ज़्यादा नतीजे पाने पर, अनुमति नहीं मिलने की गड़बड़ी दिखेगी. कुछ दस्तावेज़ ऐक्सेस कॉल कैश मेमोरी में सेव किए जा सकते हैं. साथ ही, कैश मेमोरी में सेव किए गए कॉल, इन सीमाओं में नहीं गिने जाते हैं. |
नेस्ट किए गए match स्टेटमेंट की ज़्यादा से ज़्यादा गहराई |
10 |
पाथ सेगमेंट में, नेस्ट किए गए
match स्टेटमेंट के सेट में, पाथ की ज़्यादा से ज़्यादा लंबाई की अनुमति है |
100 |
नेस्ट किए गए match स्टेटमेंट के सेट में, पाथ कैप्चर वैरिएबल की
ज़्यादा से ज़्यादा संख्या की अनुमति है |
20 |
अधिकतम फ़ंक्शन कॉल डेप्थ | 20 |
फ़ंक्शन के आर्ग्युमेंट की ज़्यादा से ज़्यादा संख्या | 7 |
हर फ़ंक्शन के लिए let वैरिएबल बाइंडिंग की ज़्यादा से ज़्यादा संख्या |
10 |
बार-बार होने वाले या साइक्लिकल फ़ंक्शन कॉल की ज़्यादा से ज़्यादा संख्या | 0 (अनुमति नहीं है) |
हर अनुरोध के लिए आकलन किए गए एक्सप्रेशन की ज़्यादा से ज़्यादा संख्या | 1,000 |
नियमसेट का ज़्यादा से ज़्यादा साइज़ | नियम, साइज़ की दो सीमाओं के मुताबिक होने चाहिए:
|
अगले चरण
- कस्टम सुरक्षा नियम की शर्तें लिखें.
- सुरक्षा नियमों से जुड़ा रेफ़रंस पढ़ें.