इस पेज का अनुवाद Cloud Translation API से किया गया है.

Cloud Firestore के सुरक्षा नियमों का स्ट्रक्चर तैयार करना

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.

ध्यान दें: सिर्फ़ उन दस्तावेज़ों को ऐक्सेस किया जा सकता है जिन्हें आपके सुरक्षा नियमों ने खास तौर पर ऐक्सेस करने की अनुमति दी है. उदाहरण के लिए, ऊपर दिखाए गए नियम सिर्फ़ cities कलेक्शन में मौजूद दस्तावेज़ों को ऐक्सेस करने की अनुमति देते हैं. इस वजह से, वे दूसरे सभी कलेक्शन में मौजूद दस्तावेज़ों को ऐक्सेस करने की अनुमति नहीं देते.

विस्तृत कार्रवाइयां

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

अगले चरण

कस्टम सुरक्षा नियम की शर्तें लिखें.
सुरक्षा नियमों से जुड़ा रेफ़रंस पढ़ें.