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

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

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

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

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 ।

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

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 है तो पहुंच की अनुमति है:

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 हो।

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

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

अगले कदम

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