क्लाउड फायरस्टोर सुरक्षा नियमों की संरचना करना

क्लाउड फायरस्टोर सुरक्षा नियम आपको अपने डेटाबेस में दस्तावेज़ों और संग्रहों तक पहुंच को नियंत्रित करने की अनुमति देते हैं। लचीले नियम सिंटैक्स आपको ऐसे नियम बनाने की अनुमति देता है जो किसी भी चीज़ से मेल खाते हैं, सभी लिखने से लेकर संपूर्ण डेटाबेस तक किसी विशिष्ट दस्तावेज़ पर संचालन तक।

यह मार्गदर्शिका सुरक्षा नियमों के मूल सिंटैक्स और संरचना का वर्णन करती है। संपूर्ण नियम सेट बनाने के लिए इस सिंटैक्स को सुरक्षा नियमों की शर्तों के साथ संयोजित करें।

सेवा और डेटाबेस घोषणा

Cloud Firestore सुरक्षा नियम हमेशा निम्न घोषणा के साथ शुरू होते हैं:

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'; आपके सुरक्षा नियमों के शीर्ष पर:

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 की पिछली सीमा भी प्रत्येक ऑपरेशन पर लागू होती है।

    उदाहरण के लिए, कल्पना करें कि आप 3 लेखन कार्यों के साथ एक बैच लिखने का अनुरोध बनाते हैं और आपके सुरक्षा नियम प्रत्येक लेखन को मान्य करने के लिए 2 दस्तावेज़ एक्सेस कॉल का उपयोग करते हैं। इस मामले में, प्रत्येक राइट अपने 10 एक्सेस कॉल्स में से 2 का उपयोग करता है और बैचेड राइट अनुरोध इसके 20 एक्सेस कॉल्स में से 6 का उपयोग करता है।

किसी भी सीमा से अधिक होने पर अनुमति अस्वीकृत त्रुटि हो जाती है।

कुछ दस्तावेज़ एक्सेस कॉल को कैश किया जा सकता है, और कैश्ड कॉल की गणना सीमा में नहीं की जाती है।

अधिकतम नेस्टेड match विवरण गहराई 10
पथ खंडों में अधिकतम पथ लंबाई, नेस्टेड match विवरण के एक सेट के भीतर अनुमत है 100
नेस्टेड match स्टेटमेंट के सेट के भीतर अधिकतम पथ कैप्चर वैरिएबल की अनुमति है 20
अधिकतम फ़ंक्शन कॉल गहराई 20
फ़ंक्शन तर्कों की अधिकतम संख्या 7
प्रति फ़ंक्शन let वेरिएबल बाइंडिंग की अधिकतम संख्या 10
पुनरावर्ती या चक्रीय फ़ंक्शन कॉल की अधिकतम संख्या 0 (अनुमति नहीं)
प्रति अनुरोध मूल्यांकित अभिव्यक्तियों की अधिकतम संख्या 1,000
एक नियम का अधिकतम आकार नियमों को दो आकार सीमाओं का पालन करना चाहिए:
  • फ़ायरबेस कंसोल से या सीएलआई से firebase deploy का उपयोग करके प्रकाशित नियम सेट टेक्स्ट स्रोत के आकार पर 256 केबी की सीमा।
  • संकलित नियमों के आकार पर 250 केबी की सीमा जिसके परिणामस्वरूप फायरबेस स्रोत को संसाधित करता है और इसे बैक-एंड पर सक्रिय बनाता है।

अगले कदम