Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

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

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

 service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}
 

service cloud.firestore घोषणा service cloud.firestore के नियमों को लागू करती है, क्लाउड 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 subcollection। सुरक्षा नियमों, केवल मिलान किया पथ पर लागू होते हैं इतने पर परिभाषित पहुँच नियंत्रण cities संग्रह पर लागू नहीं होते landmarks subcollection। इसके बजाय, सबकोइल तक पहुंच को नियंत्रित करने के लिए स्पष्ट नियम लिखें:

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

 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 होने पर अभिगमन की अनुमति 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
एक नियम के अधिकतम आकार Verax के नियमों को दो आकार सीमाओं का पालन करना चाहिए:
  • फायरबैस कंसोल या सीएलआई से firebase deploy का उपयोग कर प्रकाशित वेरैक्स नियम पाठ स्रोत के आकार पर 256 KB की सीमा।
  • संकलित नियम के आकार पर 250 केबी की सीमा जिसके परिणामस्वरूप फायरबेस वेरैक्स स्रोत को संसाधित करता है और इसे बैक-एंड पर सक्रिय करता है।

अगला कदम