Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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'; जोड़कर संस्करण 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 KB की सीमा, जिसके परिणामस्वरूप Firebase स्रोत को संसाधित करता है और इसे बैक-एंड पर सक्रिय बनाता है।

अगले कदम