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

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

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

पुष्टि करना

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

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 के सुरक्षा नियमों, डाइनैमिक तौर पर ऐक्सेस की अनुमति दे सकते हैं या अस्वीकार कर सकते हैं डेटा:

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.

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

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

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

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

कॉल और मूल्य-निर्धारण ऐक्सेस करें

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

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

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

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

फ़ंक्शन को 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();
    }
  }
}

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

नियम, फ़िल्टर नहीं हैं

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

उदाहरण के लिए, सुरक्षा के इस नियम को अपनाएं:

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());
        });
    });

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

अगले चरण