Cloud Firestore के सुरक्षा नियमों का स्ट्रक्चर तैयार करना

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

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

सेवा और डेटाबेस का एलान करना

Cloud Firestore के सुरक्षा नियम, हमेशा नीचे दिए गए एलान से शुरू होते हैं:

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

service cloud.firestore के एलान में, नियमों का दायरा इन कामों के लिए होता है Cloud Firestore की वजह से, Cloud Firestore के सुरक्षा नियमों और सुरक्षा नियमों के बीच टकराव नहीं होता Cloud Storage जैसे दूसरे प्रॉडक्ट के लिए नियम तय करती हैं.

match /databases/{database}/documents के एलान में बताया गया है कि नियमों को प्रोजेक्ट में किसी भी Cloud Firestore डेटाबेस से मैच करेगा. फ़िलहाल, हर प्रोजेक्ट में (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 होता है.

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

सुरक्षा के नियमों को लागू करते समय, इन सीमाओं का ध्यान रखें:

अगले चरण

• कस्टम सुरक्षा नियम की शर्तें लिखें.
• सुरक्षा नियमों से जुड़ा रेफ़रंस पढ़ें.