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

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

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

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

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

 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 ।

हालाँकि, ध्यान दें कि पुनरावर्ती वाइल्डकार्ड का व्यवहार नियमों के संस्करण पर निर्भर करता है।

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

 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 ।

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

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

अगला कदम

• कस्टम सुरक्षा नियम शर्तें लिखें।
• सुरक्षा नियमों का संदर्भ पढ़ें।