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

पाइपलाइन की कार्रवाइयों में कई सुविधाएं उपलब्ध हैं. हालांकि, नियमों का इंजन सिर्फ़ तुलना (जैसे, >) और लॉजिकल (जैसे, 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(...)

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

आपके पास, पुष्टि करने और क्वेरी के कॉन्टेक्स्ट की पुष्टि करने के लिए, 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();