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

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

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

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

क्लाउड फायरस्टोर सुरक्षा नियम हमेशा निम्नलिखित घोषणा से शुरू होते हैं:

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>;
    }
  }
}

पदानुक्रमित डेटा

क्लाउड फायरस्टोर में डेटा को दस्तावेज़ों के संग्रह में व्यवस्थित किया गया है, और प्रत्येक दस्तावेज़ उपसंग्रह के माध्यम से पदानुक्रम का विस्तार कर सकता है। यह समझना महत्वपूर्ण है कि सुरक्षा नियम पदानुक्रमित डेटा के साथ कैसे इंटरैक्ट करते हैं।

उस स्थिति पर विचार करें जहां 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 हो।

सुरक्षा नियम सीमाएँ

जब आप सुरक्षा नियमों के साथ काम करते हैं, तो निम्नलिखित सीमाओं पर ध्यान दें:

आप LIMIT विवरण
प्रति अनुरोध 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 केबी की सीमा, जिसके परिणामस्वरूप फायरबेस स्रोत को संसाधित करता है और इसे बैक-एंड पर सक्रिय बनाता है।

अगले कदम