Cloud Firestore के सुरक्षा नियमों के लिए लिखने की शर्तें

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

Cloud Firestore Security Rules का मुख्य बिल्डिंग ब्लॉक, शर्त है. शर्त एक बूलियन एक्सप्रेशन है. इससे यह तय होता है कि किसी कार्रवाई को अनुमति दी जानी चाहिए या नहीं. सुरक्षा नियमों का इस्तेमाल करके, ऐसी शर्तें लिखें जो उपयोगकर्ता की पुष्टि करती हैं, आने वाले डेटा की पुष्टि करती हैं या आपके डेटाबेस के अन्य हिस्सों को ऐक्सेस करती हैं.

एआई असिस्टेंस पाने के लिए, यहां दिए गए प्रॉम्प्ट को अपने एआई कोडिंग एजेंट (जैसे, Android Studio में Gemini, Antigravity, Claude Code, Codex, और Cursor) में कॉपी करें. प्रॉम्प्ट को अपनी पसंद के मुताबिक बनाया जा सकता है. साथ ही, एजेंट के साथ मिलकर उसमें बदलाव किया जा सकता है. इंस्टॉल करने के बारे में ज़्यादा जानकारी के लिए, Firebase एजेंट स्किल पर जाएं. 

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.

पुष्टि करना

सुरक्षा से जुड़े नियमों के सबसे सामान्य पैटर्न में से एक है, उपयोगकर्ता की पुष्टि की स्थिति के आधार पर ऐक्सेस को कंट्रोल करना. उदाहरण के लिए, हो सकता है कि आपका ऐप्लिकेशन सिर्फ़ साइन इन किए हुए उपयोगकर्ताओं को डेटा लिखने की अनुमति देना चाहे:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

एक और सामान्य पैटर्न यह पक्का करना है कि उपयोगकर्ता सिर्फ़ अपना डेटा पढ़ और लिख सकें:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

अगर आपका ऐप्लिकेशन, Firebase से पुष्टि करने की सुविधा या Google Cloud Identity Platform का इस्तेमाल करता है, तो request.auth वैरिएबल में डेटा का अनुरोध करने वाले क्लाइंट की पुष्टि करने की जानकारी शामिल होती है. request.auth के बारे में ज़्यादा जानकारी के लिए, रेफ़रंस दस्तावेज़ देखें.

डेटा सत्यापन

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

resource वैरिएबल, अनुरोध किए गए दस्तावेज़ को रेफ़र करता है. साथ ही, resource.data दस्तावेज़ में सेव किए गए सभी फ़ील्ड और वैल्यू का मैप होता है. resource वैरिएबल के बारे में ज़्यादा जानकारी के लिए, रेफ़रंस दस्तावेज़ देखें.

डेटा लिखते समय, हो सकता है कि आप आने वाले डेटा की तुलना मौजूदा डेटा से करना चाहें. इस मामले में, अगर आपका नियम सेट, डेटा लिखने की अनुमति देता है, तो request.resource वैरिएबल में दस्तावेज़ की आने वाली स्थिति की जानकारी होती है. update कार्रवाइयों के लिए, जो सिर्फ़ दस्तावेज़ के फ़ील्ड के सबसेट में बदलाव करती हैं, request.resource वैरिएबल में कार्रवाई के बाद, दस्तावेज़ की बाकी बची स्थिति शामिल होगी. अनचाहे या गलत डेटा अपडेट को रोकने के लिए, request.resource में फ़ील्ड की वैल्यू देखी जा सकती हैं:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

अन्य दस्तावेज़ ऐक्सेस करना

get() और exists() फ़ंक्शन का इस्तेमाल करके, आपके सुरक्षा नियम डेटाबेस में मौजूद अन्य दस्तावेज़ों के हिसाब से, आने वाले अनुरोधों का आकलन कर सकते हैं. get() और exists(), दोनों फ़ंक्शन के लिए दस्तावेज़ के पाथ की पूरी जानकारी देना ज़रूरी है. get() और exists() के लिए पाथ बनाने के लिए वैरिएबल का इस्तेमाल करते समय, आपको $(variable) सिंटैक्स का इस्तेमाल करके वैरिएबल को साफ़ तौर पर एस्केप करना होगा.

नीचे दिए गए उदाहरण में, database वैरिएबल को मैच स्टेटमेंट match /databases/{database}/documents से कैप्चर किया गया है. साथ ही, इसका इस्तेमाल पाथ बनाने के लिए किया गया है:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid));

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    }
  }
}

डेटा लिखने के लिए, getAfter() फ़ंक्शन का इस्तेमाल किया जा सकता है. इससे किसी लेन-देन या डेटा लिखने के बैच के पूरा होने के बाद, लेकिन लेन-देन या बैच के कमिट होने से पहले, दस्तावेज़ की स्थिति को ऐक्सेस किया जा सकता है. get() की तरह, getAfter() फ़ंक्शन भी दस्तावेज़ का पूरा पाथ लेता है. getAfter() का इस्तेमाल करके, डेटा लिखने के ऐसे सेट तय किए जा सकते हैं जिन्हें लेन-देन या बैच के तौर पर एक साथ पूरा करना ज़रूरी है.

कॉल की सीमाओं को ऐक्सेस करना

नियमों के हर सेट के आकलन के लिए, दस्तावेज़ ऐक्सेस करने के कॉल की एक सीमा तय की गई है:

  • एक दस्तावेज़ के अनुरोधों और क्वेरी के अनुरोधों के लिए 10.

  • एक से ज़्यादा दस्तावेज़ों को पढ़ने, लेन-देन करने, और बैच में लिखने के लिए 20. हर कार्रवाई पर, 10 की पिछली सीमा भी लागू होती है.

    उदाहरण के लिए, मान लें कि आपने तीन राइट ऑपरेशन के साथ एक बैच में राइट करने का अनुरोध किया है. साथ ही, आपके सुरक्षा नियमों में हर राइट ऑपरेशन की पुष्टि करने के लिए, दस्तावेज़ को ऐक्सेस करने के दो कॉल का इस्तेमाल किया जाता है. इस मामले में, हर राइट ऑपरेशन, अपने 10 ऐक्सेस कॉल में से दो का इस्तेमाल करता है. साथ ही, बैच में किए गए राइट ऑपरेशन का अनुरोध, अपने 20 ऐक्सेस कॉल में से छह का इस्तेमाल करता है.

इनमें से किसी भी सीमा को पार करने पर, अनुमति न मिलने से जुड़ी गड़बड़ी होती है. दस्तावेज़ को ऐक्सेस करने के लिए किए गए कुछ कॉल को कैश मेमोरी में सेव किया जा सकता है. कैश मेमोरी में सेव किए गए कॉल, तय सीमा में नहीं गिने जाते.

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

कॉल और कीमत की जानकारी ऐक्सेस करना

इन फ़ंक्शन का इस्तेमाल करने पर, आपके डेटाबेस में रीड ऑपरेशन लागू होता है. इसका मतलब है कि दस्तावेज़ों को पढ़ने के लिए आपसे शुल्क लिया जाएगा. भले ही, आपके नियम अनुरोध को अस्वीकार कर दें. बिलिंग की ज़्यादा जानकारी के लिए, Rules की कीमत देखें.

कस्टम फ़ंक्शन

जैसे-जैसे आपके सुरक्षा नियम ज़्यादा जटिल होते जाते हैं, वैसे-वैसे आपको शर्तों के सेट को ऐसे फ़ंक्शन में रैप करना पड़ सकता है जिन्हें आपके पूरे नियम सेट में फिर से इस्तेमाल किया जा सके. सुरक्षा के नियमों में कस्टम फ़ंक्शन इस्तेमाल किए जा सकते हैं. कस्टम फ़ंक्शन का सिंटैक्स, JavaScript से थोड़ा मिलता-जुलता है. हालांकि, सुरक्षा नियमों के फ़ंक्शन, डोमेन के हिसाब से तय की गई भाषा में लिखे जाते हैं. इस भाषा की कुछ अहम सीमाएं हैं:

  • फ़ंक्शन में सिर्फ़ एक return स्टेटमेंट हो सकता है. इनमें कोई अतिरिक्त लॉजिक नहीं हो सकता. उदाहरण के लिए, वे लूप को लागू नहीं कर सकते या बाहरी सेवाओं को कॉल नहीं कर सकते.
  • फ़ंक्शन, उस स्कोप से फ़ंक्शन और वैरिएबल को अपने-आप ऐक्सेस कर सकते हैं जिसमें उन्हें तय किया गया है. उदाहरण के लिए, service cloud.firestore स्कोप में तय किए गए फ़ंक्शन के पास, resource वैरिएबल और पहले से मौजूद फ़ंक्शन, जैसे कि get() और exists() का ऐक्सेस होता है.
  • फ़ंक्शन, अन्य फ़ंक्शन को कॉल कर सकते हैं. हालांकि, वे बार-बार कॉल नहीं कर सकते. कॉल स्टैक की कुल डेप्थ 10 तक सीमित है.
  • नियमों के वर्शन v2 में, फ़ंक्शन let कीवर्ड का इस्तेमाल करके वैरिएबल तय कर सकते हैं. फ़ंक्शन में ज़्यादा से ज़्यादा 10 let बाइंडिंग हो सकती हैं. हालांकि, उन्हें रिटर्न स्टेटमेंट के साथ खत्म होना चाहिए.

किसी फ़ंक्शन को function कीवर्ड के साथ तय किया जाता है. इसमें शून्य या उससे ज़्यादा आर्ग्युमेंट होते हैं. उदाहरण के लिए, हो सकता है कि आप ऊपर दिए गए उदाहरणों में इस्तेमाल की गई दो तरह की शर्तों को एक ही फ़ंक्शन में जोड़ना चाहें:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

सुरक्षा नियमों में फ़ंक्शन का इस्तेमाल करने से, उन्हें मैनेज करना आसान हो जाता है. ऐसा इसलिए, क्योंकि नियमों की जटिलता बढ़ती जाती है.

नियम, फ़िल्टर नहीं होते

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

उदाहरण के लिए, यहां दिया गया सुरक्षा नियम देखें:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

अस्वीकार किया गया: यह नियम इस क्वेरी को अस्वीकार करता है, क्योंकि नतीजों के सेट में ऐसे दस्तावेज़ शामिल हो सकते हैं जिनमें visibility, public नहीं है:

वेब 
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

अनुमति है: यह नियम, इस क्वेरी की अनुमति देता है, क्योंकि where("visibility", "==", "public") क्लॉज़ यह गारंटी देता है कि नतीजों का सेट, नियम की शर्त को पूरा करता है:

वेब 
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

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

अगले चरण