Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

क्लाउड फायरस्टार सुरक्षा नियमों के लिए लेखन की स्थिति

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

क्लाउड फायरस्टार सुरक्षा नियमों का प्राथमिक भवन ब्लॉक शर्त है। एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या इनकार कर दिया जाना चाहिए। उपयोगकर्ता प्रमाणीकरण की जाँच करने, आने वाले डेटा को मान्य करने या यहां तक ​​कि आपके डेटाबेस के अन्य हिस्सों तक पहुंचने के लिए सुरक्षा नियमों का उपयोग करें।

प्रमाणीकरण

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

 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 Authentication का उपयोग करता है, तो request.auth चर में डेटा का अनुरोध करने वाले क्लाइंट के लिए प्रमाणीकरण जानकारी होती है। request.auth बारे में अधिक जानकारी के लिए, संदर्भ प्रलेखन देखें।

डेटा मान्य

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

 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() लिए पथों का उपयोग करते हुए 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 की पिछली सीमा भी लागू होती है।

    उदाहरण के लिए, कल्पना करें कि आप 3 लिखने के संचालन के साथ एक बैच लिखने का अनुरोध बनाते हैं और यह कि आपके सुरक्षा नियम प्रत्येक लेखन को मान्य करने के लिए 2 दस्तावेज़ एक्सेस कॉल का उपयोग करते हैं। इस स्थिति में, प्रत्येक लेखन अपने 10 एक्सेस कॉल में से 2 का उपयोग करता है और बैच लेखन अनुरोध अपने 20 एक्सेस कॉल में से 6 का उपयोग करता है।

अनुमति से वंचित त्रुटि में सीमा परिणाम अधिक होने से। कुछ डॉक्यूमेंट एक्सेस कॉल्स को कैश किया जा सकता है, और कैश्ड कॉल्स की सीमा नहीं होती है।

ये सीमाएं लेन-देन और बैचों को कैसे प्रभावित करती हैं, इसकी विस्तृत व्याख्या के लिए, परमाणु संचालन को सुरक्षित करने के लिए मार्गदर्शिका देखें।

कॉल और मूल्य निर्धारण पर पहुँचें

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

कस्टम कार्य

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

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

एक फ़ंक्शन को function कीवर्ड के साथ परिभाषित किया गया 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());
        });
    });

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

अगला कदम