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
कलेक्शन में मौजूद दस्तावेज़ और सब-कलेक्शन.
इसके लिए, आपको सबसे ऊपर 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 |
नियमसेट का ज़्यादा से ज़्यादा साइज़ | नियमसेट को दो साइज़ की सीमाओं का पालन करना चाहिए:
|
अगले चरण
- कस्टम सुरक्षा नियम की शर्तें लिखें.
- सुरक्षा नियमों से जुड़ा रेफ़रंस पढ़ें.