पाइपलाइन के ऑपरेशन के लिए सुरक्षा के नियम

पाइपलाइन ऑपरेशन में कई सुविधाएं उपलब्ध होती हैं. हालांकि, नियमों का इंजन सिर्फ़ तुलना (जैसे, >) और लॉजिकल (जैसे, or) फ़िल्टर को पहचान सकता है. इससे यह पक्का किया जा सकता है कि शर्तों को पूरा किया जा रहा है और सुरक्षा बनी हुई है.

काम करने वाले फ़िल्टर एक्सप्रेशन

पाइपलाइन के ऑपरेशन को आपके नियमों के हिसाब से सेट की गई सीमाओं के अंदर रखने के लिए, उसे कॉन्स्टेंट के ख़िलाफ़ लॉजिकल और तुलना करने वाले ऑपरेटर का इस्तेमाल करना होगा. नियम इंजन, इन फ़िल्टर टाइप को पहचानता है:

• तुलनाएं: eq, neq, gt, gte, lt, lte, in, arrayContains.
• लॉजिकल: and, or.

यहां कुछ उदाहरण दिए गए हैं:

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

ध्यान दें: क्वेरी को सीमित करने के लिए, जटिल एक्सप्रेशन का इस्तेमाल नहीं किया जा सकता. जैसे, फ़िल्टर में अंकगणित (उदाहरण के लिए, where(eq("foo" * 2, 10))) या स्ट्रिंग फ़ंक्शन, जैसे कि strContains.

अनुरोध की प्रॉपर्टी

पुष्टि करने और क्वेरी के संदर्भ की पुष्टि करने के लिए, request ऑब्जेक्ट का इस्तेमाल किया जा सकता है. हालांकि, स्टैंडर्ड क्वेरी में उपलब्ध कुछ प्रॉपर्टी, पाइपलाइन ऑपरेशन में काम नहीं करती हैं.

इस्तेमाल की जा सकने वाली प्रॉपर्टी

नया इंजन, इन प्रॉपर्टी के साथ काम करता रहेगा:

• request.auth: उपयोगकर्ता के यूआईडी और टोकन डेटा को ऐक्सेस करता है.
• request.method: इससे ऑपरेशन की पहचान होती है. उदाहरण के लिए, get, list.
• request.path: ऐक्सेस किए जा रहे संसाधन का पाथ.
• request.time: यह अनुरोध का सर्वर-साइड टाइमस्टैंप है.

ऐसी प्रॉपर्टी जिन्हें इस्तेमाल नहीं किया जा सकता

पाइपलाइन ऑपरेशन के नियमों की जांच के लिए, request.query प्रॉपर्टी का इस्तेमाल नहीं किया जा सकता. जैसे, limit, offset, और orderBy. ऐसा इसलिए, क्योंकि मल्टी-स्टेज क्वेरी में इन वैल्यू का पता लगाना मुश्किल होता है.

पाइपलाइन के स्टेज को मैनेज करना और अनुमतियां

पाइपलाइन के अलग-अलग चरण होते हैं. ये चरण, सुरक्षा नियमों में मौजूद खास कार्रवाइयों से मैप होते हैं:

• allow list अनुमतियां: ये collection(), collectionGroup(), और database() चरणों के दौरान ट्रिगर होती हैं.
• allow get अनुमतियां: यह documents() स्टेज से ट्रिगर होती है. इसे बैच get ऑपरेशन की तरह ही माना जाता है.
• लिटरल स्टेज: literals() स्टेज, डेटाबेस से नहीं पढ़ता, लेकिन इससे लागत लग सकती है. इसका गलत इस्तेमाल रोकने के लिए, इसे किसी दूसरे चरण (जैसे कि collection()) के साथ जोड़ा जाना चाहिए. इसकी पुष्टि नियमों के हिसाब से की जा सकती है.

फ़ील्ड में बदलाव करने के चरण

नियम सिर्फ़ सेव किए गए डेटा पर लागू होते हैं, न कि निकाली गई वैल्यू पर. अगर किसी पाइपलाइन में ऐसे चरण शामिल हैं जो फ़ील्ड में बदलाव करते हैं (उदाहरण के लिए, add_fields(...), replace_with(...), select(...), remove_fields(...)), तो उस चरण के बाद, नियमों का इंजन फ़िल्टर की शर्तों को लागू करना बंद कर देता है. यह पक्का करने के लिए कि नियम आपकी उम्मीद के मुताबिक काम कर रहे हैं, फ़िल्टर के चरणों (जैसे, where) को उन चरणों से पहले रखें जो सेव किए गए ओरिजनल दस्तावेज़ों में बदलाव कर सकते हैं.

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

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

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

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

अनुमति है: इस नियम के तहत, इस पाइपलाइन को अनुमति दी गई है, क्योंकि where(eq(field("visibility"), constant("public"))) स्टेज, बदलाव करने वाले किसी भी स्टेज से पहले होता है:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();