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

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

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

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.

सेवा और डेटाबेस से जुड़ा एलान

Cloud Firestore Security Rules हमेशा इस एलान के साथ शुरू करें:

service cloud.firestore {
  // The {database} wildcard allows the rules to reference any database,
  // but these rules are only active on databases where they are explicitly deployed.
  match /databases/{database}/documents {
    // ...
  }
}

service cloud.firestore डिक्लेरेशन, नियमों को के नियमों तक सीमित करता है. इससे Cloud Firestore Security Rules और Cloud Storage जैसे अन्य प्रॉडक्ट के नियमों के बीच होने वाले टकराव को रोका जा सकता है.

match /databases/{database}/documents एलान से पता चलता है कि नियम, प्रोजेक्ट में मौजूद किसी भी नियम के डेटाबेस से मैच होने चाहिए. किसी प्रोजेक्ट में ज़्यादा से ज़्यादा 100 डेटाबेस हो सकते हैं. हालांकि, बनाए गए पहले डेटाबेस को ही डिफ़ॉल्ट के तौर पर सेट किया जाता है.

Cloud Firestore Security Rules, आपके प्रोजेक्ट में मौजूद हर डेटाबेस पर अलग-अलग लागू होती हैं. इसका मतलब है कि अगर आपने कई डेटाबेस बनाए हैं, तो आपको हर डेटाबेस के लिए अलग-अलग नियम मैनेज और डिप्लॉय करने होंगे. अपडेट डिप्लॉय करने के बारे में ज़्यादा जानने के लिए, अपने अपडेट डिप्लॉय करना लेख पढ़ें.

पढ़ने/लिखने के बुनियादी नियम

बुनियादी नियमों में एक 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>;
    }
  }
}

हैरारकीकल डेटा

Rules में डेटा को दस्तावेज़ों के कलेक्शन में व्यवस्थित किया जाता है. साथ ही, हर दस्तावेज़ सब-कलेक्शन के ज़रिए हैरारकी को बढ़ा सकता है. यह समझना ज़रूरी है कि सुरक्षा के नियम, हैरारकी वाले डेटा के साथ कैसे इंटरैक्ट करते हैं.

मान लें कि 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>;
   }
 }
}

अगर कलेक्शन ग्रुप क्वेरी का इस्तेमाल किया जाता है, तो आपको दूसरे वर्शन का इस्तेमाल करना होगा. इसके लिए, कलेक्शन ग्रुप क्वेरी को सुरक्षित करना लेख पढ़ें.

ओवरलैप होने वाले मैच स्टेटमेंट

ऐसा हो सकता है कि कोई दस्तावेज़, एक से ज़्यादा 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 हो.

सुरक्षा से जुड़े नियम की सीमाएं

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

अगले चरण

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