Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

सुरक्षा नियम भाषा

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

फायरबेस सुरक्षा नियम लचीली, शक्तिशाली, कस्टम भाषाओं का लाभ उठाते हैं जो जटिलता और ग्रैन्युलैरिटी की एक विस्तृत श्रृंखला का समर्थन करते हैं। आप अपने नियमों को उतना विशिष्ट या सामान्य बना सकते हैं जितना आपके ऐप के लिए उपयुक्त हो। रीयलटाइम डेटाबेस नियम एक सिंटैक्स का उपयोग करते हैं जो JSON संरचना में जावास्क्रिप्ट जैसा दिखता है। क्लाउड फायरस्टोर और क्लाउड स्टोरेज नियम कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) पर आधारित भाषा का उपयोग करते हैं, जो सीईएल पर match के साथ बनता है और सशर्त रूप से दी गई पहुंच का समर्थन करने वाले बयानों allow है।

चूंकि ये कस्टम भाषाएं हैं, हालांकि, सीखने की अवस्था है। नियमों की भाषा को बेहतर ढंग से समझने के लिए इस गाइड का उपयोग करें क्योंकि आप अधिक जटिल नियमों में गहराई से उतरते हैं।

किसी उत्पाद के नियमों के बारे में अधिक जानने के लिए उसका चयन करें।

बुनियादी संरचना

क्लाउड फायरस्टोर

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

जब आप नियम बनाते हैं तो निम्नलिखित प्रमुख अवधारणाओं को समझना महत्वपूर्ण है:

  • अनुरोध: allow कथन में लागू की गई विधि या विधियाँ। ये वे तरीके हैं जिन्हें आप चलाने की अनुमति दे रहे हैं। मानक तरीके हैं: get करें, list बनाएं, create , update और deleteread और write की सुविधा के तरीके निर्दिष्ट डेटाबेस या भंडारण पथ पर व्यापक पढ़ने और लिखने की अनुमति देते हैं।
  • पथ: डेटाबेस या भंडारण स्थान, जिसे यूआरआई पथ के रूप में दर्शाया गया है।
  • नियम: allow कथन, जिसमें एक शर्त शामिल है जो अनुरोध की अनुमति देती है यदि यह सत्य का मूल्यांकन करती है।

इनमें से प्रत्येक अवधारणा को नीचे और विस्तार से वर्णित किया गया है।

घन संग्रहण

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में फायरबेस सुरक्षा नियम निम्नलिखित संरचना और सिंटैक्स का उपयोग करते हैं:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

जब आप नियम बनाते हैं तो निम्नलिखित प्रमुख अवधारणाओं को समझना महत्वपूर्ण है:

  • अनुरोध: allow कथन में लागू की गई विधि या विधियाँ। ये वे तरीके हैं जिन्हें आप चलाने की अनुमति दे रहे हैं। मानक तरीके हैं: get करें, list बनाएं, create , update और deleteread और write की सुविधा के तरीके निर्दिष्ट डेटाबेस या भंडारण पथ पर व्यापक पढ़ने और लिखने की अनुमति देते हैं।
  • पथ: डेटाबेस या भंडारण स्थान, जिसे यूआरआई पथ के रूप में दर्शाया गया है।
  • नियम: allow कथन, जिसमें एक शर्त शामिल है जो अनुरोध की अनुमति देती है यदि यह सत्य का मूल्यांकन करती है।

इनमें से प्रत्येक अवधारणा को नीचे और विस्तार से वर्णित किया गया है।

रीयलटाइम डेटाबेस

रीयलटाइम डेटाबेस में, Firebase सुरक्षा नियमों में JSON दस्तावेज़ में मौजूद JavaScript जैसे भाव होते हैं।

वे निम्नलिखित सिंटैक्स का उपयोग करते हैं:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

नियम में तीन बुनियादी तत्व हैं:

  • पथ: डेटाबेस स्थान। यह आपके डेटाबेस की JSON संरचना को प्रतिबिंबित करता है।
  • अनुरोध: ये वे तरीके हैं जिनका उपयोग नियम पहुँच प्रदान करने के लिए करता है। read और write के नियम व्यापक पढ़ने और लिखने की पहुंच प्रदान करते हैं, जबकि validate नियम आने वाले या मौजूदा डेटा के आधार पर पहुंच प्रदान करने के लिए द्वितीयक सत्यापन के रूप में कार्य करते हैं।
  • शर्त: वह शर्त जो अनुरोध की अनुमति देती है यदि वह सत्य का मूल्यांकन करता है।

नियम निर्माण

क्लाउड फायरस्टोर

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में एक नियम के मूल तत्व इस प्रकार हैं:

  • service घोषणा: Firebase उत्पाद की घोषणा करता है जिस पर नियम लागू होते हैं।
  • match ब्लॉक: डेटाबेस या स्टोरेज बकेट में एक पथ को परिभाषित करता है जिस पर नियम लागू होते हैं।
  • allow कथन: पहुँच प्रदान करने के लिए शर्तें प्रदान करता है, विधियों द्वारा विभेदित। समर्थित विधियों में शामिल हैं: get करें, list बनाएं, create , update , delete , और सुविधा विधियां read और write
  • वैकल्पिक function घोषणाएं: एकाधिक नियमों में उपयोग के लिए शर्तों को संयोजित करने और लपेटने की क्षमता प्रदान करें।

service में allow के साथ एक या अधिक match ब्लॉक होते हैं जो अनुरोधों तक पहुंच प्रदान करने वाली शर्तें प्रदान करते हैं। request और resource चर नियम शर्तों में उपयोग के लिए उपलब्ध हैं। फायरबेस सुरक्षा नियम भाषा भी function घोषणाओं का समर्थन करती है।

सिंटैक्स संस्करण

syntax स्टेटमेंट स्रोत लिखने के लिए उपयोग की जाने वाली फ़ायरबेस नियम भाषा के संस्करण को इंगित करता है। भाषा का नवीनतम संस्करण v2 है।

rules_version = '2';
service cloud.firestore {
...
}

यदि कोई rules_version विवरण नहीं दिया गया है, तो आपके नियमों का मूल्यांकन v1 इंजन का उपयोग करके किया जाएगा।

सेवा

service घोषणा परिभाषित करती है कि आपके नियम किस Firebase उत्पाद या सेवा पर लागू होते हैं। आप प्रति स्रोत फ़ाइल में केवल एक service घोषणा शामिल कर सकते हैं।

क्लाउड फायरस्टोर

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

घन संग्रहण

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

यदि आप Firebase CLI का उपयोग करके Cloud Firestore और Cloud Storage दोनों के लिए नियम परिभाषित कर रहे हैं, तो आपको उन्हें अलग-अलग फ़ाइलों में बनाए रखना होगा।

मिलान

एक match ब्लॉक एक path पैटर्न की घोषणा करता है जो अनुरोधित ऑपरेशन (आने वाले request.path ) के पथ के विरुद्ध मेल खाता है। match के मुख्य भाग में एक या एक से अधिक नेस्टेड match ब्लॉक होने चाहिए, स्टेटमेंट्स या function डिक्लेरेशन allow होनी चाहिए। नेस्टेड match ब्लॉक में पथ पैरेंट match ब्लॉक में पथ के सापेक्ष है।

path पैटर्न एक निर्देशिका जैसा नाम है जिसमें चर या वाइल्डकार्ड शामिल हो सकते हैं। path पैटर्न एकल-पथ खंड और बहु-पथ खंड मिलान के लिए अनुमति देता है। path में बाध्य कोई भी चर match दायरे या किसी भी नेस्टेड स्कोप के भीतर दिखाई देता है जहां path घोषित किया जाता है।

path पैटर्न के विरुद्ध मिलान आंशिक या पूर्ण हो सकते हैं:

  • आंशिक मिलान: path पैटर्न request.path का उपसर्ग-मिलान है।
  • पूर्ण मिलान: path पैटर्न संपूर्ण request.path से मेल खाता है।

जब एक पूर्ण मिलान किया जाता है तो ब्लॉक के भीतर के नियमों का मूल्यांकन किया जाता है। जब एक आंशिक मिलान किया जाता है तो नेस्टेड match नियमों का परीक्षण यह देखने के लिए किया जाता है कि कोई नेस्टेड path मिलान को पूरा करेगा या नहीं।

प्रत्येक पूर्ण match के नियमों का मूल्यांकन यह निर्धारित करने के लिए किया जाता है कि अनुरोध की अनुमति दी जाए या नहीं। यदि कोई मिलान नियम पहुँच प्रदान करता है, तो अनुरोध की अनुमति है। यदि कोई मेल खाने वाला नियम पहुंच प्रदान नहीं करता है, तो अनुरोध अस्वीकार कर दिया जाता है।

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

जैसा कि ऊपर दिए गए उदाहरण से पता चलता है, path घोषणाएँ निम्नलिखित चर का समर्थन करती हैं:

  • सिंगल-सेगमेंट वाइल्डकार्ड: एक वाइल्डकार्ड वैरिएबल को कर्ली ब्रेसिज़ में एक वेरिएबल लपेटकर पथ में घोषित किया जाता है: {variable} । यह वेरिएबल match स्टेटमेंट में एक string के रूप में एक्सेस किया जा सकता है।
  • रिकर्सिव वाइल्डकार्ड: रिकर्सिव, या मल्टी-सेगमेंट, वाइल्डकार्ड एक पथ पर या उसके नीचे कई पथ खंडों से मेल खाता है। यह वाइल्डकार्ड आपके द्वारा सेट किए गए स्थान के नीचे के सभी पथों से मेल खाता है। आप अपने सेगमेंट वेरिएबल के अंत में =** स्ट्रिंग जोड़कर इसे घोषित कर सकते हैं: {variable=**} । यह वेरिएबल match स्टेटमेंट में path ऑब्जेक्ट के रूप में एक्सेस किया जा सकता है।

अनुमति देना

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

यदि विधि के लिए allow नियमों में से कोई भी संतुष्ट है, तो अनुरोध की अनुमति है। इसके अतिरिक्त, यदि कोई व्यापक नियम पहुँच प्रदान करता है, तो नियम पहुँच प्रदान करते हैं और ऐसे किसी भी अधिक विस्तृत नियमों की उपेक्षा करते हैं जो पहुँच को सीमित कर सकते हैं।

निम्नलिखित उदाहरण पर विचार करें, जहां कोई भी उपयोगकर्ता अपनी किसी भी फाइल को पढ़ या हटा सकता है। अधिक बारीक नियम केवल तभी लिखने की अनुमति देता है जब लिखने का अनुरोध करने वाला उपयोगकर्ता फ़ाइल का स्वामी हो और फ़ाइल PNG हो। एक उपयोगकर्ता उपपथ पर किसी भी फाइल को हटा सकता है - भले ही वे पीएनजी न हों - क्योंकि पहले का नियम इसकी अनुमति देता है।

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

तरीका

प्रत्येक allow कथन में एक विधि शामिल होती है जो उसी विधि के आने वाले अनुरोधों तक पहुंच प्रदान करती है।

तरीका आग्रह का प्रकार
सुविधा के तरीके
read किसी भी प्रकार का पढ़ने का अनुरोध
write किसी भी प्रकार का लेखन अनुरोध
मानक तरीके
get एकल दस्तावेज़ों या फ़ाइलों के लिए अनुरोध पढ़ें
list प्रश्नों और संग्रह के लिए अनुरोध पढ़ें
create नए दस्तावेज़ या फ़ाइलें लिखें
update मौजूदा डेटाबेस दस्तावेज़ों को लिखें या फ़ाइल मेटाडेटा अपडेट करें
delete डेटा हटाएं

आप समान path घोषणा में समान match ब्लॉक या परस्पर विरोधी लेखन विधियों में पढ़ने के तरीकों को ओवरलैप नहीं कर सकते।

उदाहरण के लिए, निम्नलिखित नियम विफल हो जाएंगे:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

समारोह

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

  • फ़ंक्शंस में केवल एक return स्टेटमेंट हो सकता है। उनमें कोई अतिरिक्त तर्क नहीं हो सकता। उदाहरण के लिए, वे लूप निष्पादित नहीं कर सकते हैं या बाहरी सेवाओं को कॉल नहीं कर सकते हैं।
  • फ़ंक्शंस स्वचालित रूप से फ़ंक्शंस और वेरिएबल्स को उस दायरे से एक्सेस कर सकते हैं जिसमें उन्हें परिभाषित किया गया है। उदाहरण के लिए, service cloud.firestore स्कोप के भीतर परिभाषित एक फंक्शन के पास resource वेरिएबल और बिल्ट-इन फंक्शन्स जैसे कि get() और exists() तक पहुंच है।
  • फ़ंक्शंस अन्य फ़ंक्शंस को कॉल कर सकते हैं लेकिन रिकर्स नहीं कर सकते हैं। कुल कॉल स्टैक गहराई 20 तक सीमित है।
  • नियम संस्करण 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();
    }
  }
}

यहाँ एक उदाहरण है जो फ़ंक्शन तर्क दिखा रहा है और असाइनमेंट देता है। बता दें कि असाइनमेंट स्टेटमेंट को सेमी-कोलन द्वारा अलग किया जाना चाहिए।

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

ध्यान दें कि कैसे isAdmin असाइनमेंट व्यवस्थापक संग्रह के लुकअप को लागू करता है। अनावश्यक लुकअप की आवश्यकता के बिना आलसी मूल्यांकन के लिए, && (AND) और || की शॉर्ट-सर्किटिंग प्रकृति का लाभ उठाएं। (या) दूसरे फ़ंक्शन को कॉल करने के लिए तुलना केवल तभी होती है जब isAuthor को सत्य ( && तुलनाओं के लिए) या गलत (के लिए || तुलना) दिखाया जाता है।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

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

घन संग्रहण

क्लाउड फायरस्टोर और क्लाउड स्टोरेज में एक नियम के मूल तत्व इस प्रकार हैं:

  • service घोषणा: Firebase उत्पाद की घोषणा करता है जिस पर नियम लागू होते हैं।
  • match ब्लॉक: डेटाबेस या स्टोरेज बकेट में एक पथ को परिभाषित करता है जिस पर नियम लागू होते हैं।
  • allow कथन: पहुँच प्रदान करने के लिए शर्तें प्रदान करता है, विधियों द्वारा विभेदित। समर्थित विधियों में शामिल हैं: get करें, list बनाएं, create , update , delete , और सुविधा विधियां read और write
  • वैकल्पिक function घोषणाएं: एकाधिक नियमों में उपयोग के लिए शर्तों को संयोजित करने और लपेटने की क्षमता प्रदान करें।

service में allow के साथ एक या अधिक match ब्लॉक होते हैं जो अनुरोधों तक पहुंच प्रदान करने वाली शर्तें प्रदान करते हैं। request और resource चर नियम शर्तों में उपयोग के लिए उपलब्ध हैं। फायरबेस सुरक्षा नियम भाषा भी function घोषणाओं का समर्थन करती है।

सिंटैक्स संस्करण

syntax स्टेटमेंट स्रोत लिखने के लिए उपयोग की जाने वाली फ़ायरबेस नियम भाषा के संस्करण को इंगित करता है। भाषा का नवीनतम संस्करण v2 है।

rules_version = '2';
service cloud.firestore {
...
}

यदि कोई rules_version विवरण नहीं दिया गया है, तो आपके नियमों का मूल्यांकन v1 इंजन का उपयोग करके किया जाएगा।

सेवा

service घोषणा परिभाषित करती है कि आपके नियम किस Firebase उत्पाद या सेवा पर लागू होते हैं। आप प्रति स्रोत फ़ाइल में केवल एक service घोषणा शामिल कर सकते हैं।

क्लाउड फायरस्टोर

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

घन संग्रहण

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

यदि आप Firebase CLI का उपयोग करके Cloud Firestore और Cloud Storage दोनों के लिए नियम परिभाषित कर रहे हैं, तो आपको उन्हें अलग-अलग फ़ाइलों में बनाए रखना होगा।

मिलान

एक match ब्लॉक एक path पैटर्न की घोषणा करता है जो अनुरोधित ऑपरेशन (आने वाले request.path ) के पथ के विरुद्ध मेल खाता है। match के मुख्य भाग में एक या एक से अधिक नेस्टेड match ब्लॉक होने चाहिए, स्टेटमेंट्स या function डिक्लेरेशन allow होनी चाहिए। नेस्टेड match ब्लॉक में पथ पैरेंट match ब्लॉक में पथ के सापेक्ष है।

path पैटर्न एक निर्देशिका जैसा नाम है जिसमें चर या वाइल्डकार्ड शामिल हो सकते हैं। path पैटर्न एकल-पथ खंड और बहु-पथ खंड मिलान के लिए अनुमति देता है। path में बाध्य कोई भी चर match दायरे या किसी भी नेस्टेड स्कोप के भीतर दिखाई देता है जहां path घोषित किया जाता है।

path पैटर्न के विरुद्ध मिलान आंशिक या पूर्ण हो सकते हैं:

  • आंशिक मिलान: path पैटर्न request.path का उपसर्ग-मिलान है।
  • पूर्ण मिलान: path पैटर्न संपूर्ण request.path से मेल खाता है।

जब एक पूर्ण मिलान किया जाता है तो ब्लॉक के भीतर के नियमों का मूल्यांकन किया जाता है। जब एक आंशिक मिलान किया जाता है तो नेस्टेड match नियमों का परीक्षण यह देखने के लिए किया जाता है कि कोई नेस्टेड path मिलान को पूरा करेगा या नहीं।

प्रत्येक पूर्ण match के नियमों का मूल्यांकन यह निर्धारित करने के लिए किया जाता है कि अनुरोध की अनुमति दी जाए या नहीं। यदि कोई मिलान नियम पहुँच प्रदान करता है, तो अनुरोध की अनुमति है। यदि कोई मेल खाने वाला नियम पहुंच प्रदान नहीं करता है, तो अनुरोध अस्वीकार कर दिया जाता है।

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

जैसा कि ऊपर दिए गए उदाहरण से पता चलता है, path घोषणाएँ निम्नलिखित चर का समर्थन करती हैं:

  • सिंगल-सेगमेंट वाइल्डकार्ड: एक वाइल्डकार्ड वैरिएबल को कर्ली ब्रेसिज़ में एक वेरिएबल लपेटकर पथ में घोषित किया जाता है: {variable} । यह वेरिएबल match स्टेटमेंट में एक string के रूप में एक्सेस किया जा सकता है।
  • रिकर्सिव वाइल्डकार्ड: रिकर्सिव, या मल्टी-सेगमेंट, वाइल्डकार्ड एक पथ पर या उसके नीचे कई पथ खंडों से मेल खाता है। यह वाइल्डकार्ड आपके द्वारा सेट किए गए स्थान के नीचे के सभी पथों से मेल खाता है। आप अपने सेगमेंट वेरिएबल के अंत में =** स्ट्रिंग जोड़कर इसे घोषित कर सकते हैं: {variable=**} । यह वेरिएबल match स्टेटमेंट में path ऑब्जेक्ट के रूप में एक्सेस किया जा सकता है।

अनुमति देना

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

यदि विधि के लिए allow नियमों में से कोई भी संतुष्ट है, तो अनुरोध की अनुमति है। इसके अतिरिक्त, यदि कोई व्यापक नियम पहुँच प्रदान करता है, तो नियम पहुँच प्रदान करते हैं और ऐसे किसी भी अधिक विस्तृत नियमों की उपेक्षा करते हैं जो पहुँच को सीमित कर सकते हैं।

निम्नलिखित उदाहरण पर विचार करें, जहां कोई भी उपयोगकर्ता अपनी किसी भी फाइल को पढ़ या हटा सकता है। अधिक बारीक नियम केवल तभी लिखने की अनुमति देता है जब लिखने का अनुरोध करने वाला उपयोगकर्ता फ़ाइल का स्वामी हो और फ़ाइल PNG हो। एक उपयोगकर्ता उपपथ पर किसी भी फाइल को हटा सकता है - भले ही वे पीएनजी न हों - क्योंकि पहले का नियम इसकी अनुमति देता है।

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

तरीका

प्रत्येक allow कथन में एक विधि शामिल होती है जो उसी विधि के आने वाले अनुरोधों तक पहुंच प्रदान करती है।

तरीका आग्रह का प्रकार
सुविधा के तरीके
read किसी भी प्रकार का पढ़ने का अनुरोध
write किसी भी प्रकार का लेखन अनुरोध
मानक तरीके
get एकल दस्तावेज़ों या फ़ाइलों के लिए अनुरोध पढ़ें
list प्रश्नों और संग्रह के लिए अनुरोध पढ़ें
create नए दस्तावेज़ या फ़ाइलें लिखें
update मौजूदा डेटाबेस दस्तावेज़ों को लिखें या फ़ाइल मेटाडेटा अपडेट करें
delete डेटा हटाएं

आप समान path घोषणा में समान match ब्लॉक या परस्पर विरोधी लेखन विधियों में पढ़ने के तरीकों को ओवरलैप नहीं कर सकते।

उदाहरण के लिए, निम्नलिखित नियम विफल हो जाएंगे:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

समारोह

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

  • फ़ंक्शंस में केवल एक return स्टेटमेंट हो सकता है। उनमें कोई अतिरिक्त तर्क नहीं हो सकता। उदाहरण के लिए, वे लूप निष्पादित नहीं कर सकते हैं या बाहरी सेवाओं को कॉल नहीं कर सकते हैं।
  • फ़ंक्शंस स्वचालित रूप से फ़ंक्शंस और वेरिएबल्स को उस दायरे से एक्सेस कर सकते हैं जिसमें उन्हें परिभाषित किया गया है। उदाहरण के लिए, service cloud.firestore स्कोप के भीतर परिभाषित एक फंक्शन के पास resource वेरिएबल और बिल्ट-इन फंक्शन्स जैसे कि get() और exists() तक पहुंच है।
  • फ़ंक्शंस अन्य फ़ंक्शंस को कॉल कर सकते हैं लेकिन रिकर्स नहीं कर सकते हैं। कुल कॉल स्टैक गहराई 20 तक सीमित है।
  • नियम संस्करण 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();
    }
  }
}

यहाँ एक उदाहरण है जो फ़ंक्शन तर्क दिखा रहा है और असाइनमेंट देता है। बता दें कि असाइनमेंट स्टेटमेंट को सेमी-कोलन द्वारा अलग किया जाना चाहिए।

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

ध्यान दें कि कैसे isAdmin असाइनमेंट व्यवस्थापक संग्रह के लुकअप को लागू करता है। अनावश्यक लुकअप की आवश्यकता के बिना आलसी मूल्यांकन के लिए, && (AND) और || की शॉर्ट-सर्किटिंग प्रकृति का लाभ उठाएं। (या) दूसरे फ़ंक्शन को कॉल करने के लिए तुलना केवल तभी होती है जब isAuthor को सत्य ( && तुलनाओं के लिए) या गलत (के लिए || तुलना) दिखाया जाता है।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

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

रीयलटाइम डेटाबेस

जैसा कि ऊपर बताया गया है, रीयलटाइम डेटाबेस नियमों में तीन बुनियादी तत्व शामिल हैं: डेटाबेस की JSON संरचना के दर्पण के रूप में डेटाबेस स्थान, अनुरोध प्रकार, और पहुँच प्रदान करने की स्थिति।

डेटाबेस स्थान

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

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

आपके नियमों को उस संरचना को प्रतिबिंबित करना चाहिए। उदाहरण के लिए:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

जैसा कि ऊपर दिए गए उदाहरण से पता चलता है, रीयलटाइम डेटाबेस नियम पथ खंडों से मेल खाने के लिए $location चर का समर्थन करते हैं। पथ के किसी भी चाइल्ड नोड से अपने नियम का मिलान करने के लिए अपने पथ खंड के सामने $ उपसर्ग का उपयोग करें।

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

आप निरंतर पथ नामों के साथ समानांतर में $variable का भी उपयोग कर सकते हैं।

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }

तरीका

रीयलटाइम डेटाबेस में तीन प्रकार के नियम होते हैं। इन नियमों में से दो प्रकार - read और write - आने वाले अनुरोध की विधि पर लागू होते हैं। validate नियम प्रकार डेटा संरचनाओं को लागू करता है और डेटा के प्रारूप और सामग्री को मान्य करता है। नियम चलाते हैं। सत्यापित करने के बाद नियम .write .validate पहुंच प्रदान करता है।

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

डिफ़ॉल्ट रूप से, यदि कोई नियम इसकी अनुमति नहीं देता है, तो पथ पर पहुंच अस्वीकार कर दी जाती है।

भवन की स्थिति

क्लाउड फायरस्टोर

एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या अस्वीकार की जानी चाहिए। request और resource चर उन स्थितियों के लिए संदर्भ प्रदान करते हैं।

request चर

request चर में निम्नलिखित फ़ील्ड और संबंधित जानकारी शामिल है:

request.auth

एक JSON वेब टोकन (JWT) जिसमें Firebase प्रमाणीकरण से प्रमाणीकरण क्रेडेंशियल शामिल हैं। auth टोकन में मानक दावों का एक सेट और आपके द्वारा Firebase प्रमाणीकरण के माध्यम से बनाए गए सभी कस्टम दावे शामिल होते हैं। Firebase सुरक्षा नियमों और प्रमाणीकरण के बारे में अधिक जानें।

request.method

request.method कोई भी मानक विधि या कस्टम विधि हो सकती है। read और write की सुविधा विधियाँ लेखन नियमों को सरल बनाने के लिए भी मौजूद हैं जो क्रमशः सभी-पढ़ने के लिए या सभी केवल-लिखने के मानक तरीकों पर लागू होते हैं।

request.params

request.params में कोई भी डेटा शामिल है जो विशेष रूप से request.resource से संबंधित नहीं है जो मूल्यांकन के लिए उपयोगी हो सकता है। व्यवहार में, यह नक्शा सभी मानक विधियों के लिए खाली होना चाहिए, और इसमें कस्टम विधियों के लिए गैर-संसाधन डेटा होना चाहिए। सेवाओं को सावधान रहना चाहिए कि पैरा के रूप में प्रस्तुत किसी भी कुंजी और मूल्यों के प्रकार का नाम बदलें या संशोधित न करें।

request.path

request.path लक्ष्य resource के लिए पथ है। पथ सेवा के सापेक्ष है। गैर-यूआरएल सुरक्षित वर्णों वाले पथ खंड जैसे / यूआरएल-एन्कोडेड हैं।

resource चर

resource सेवा के भीतर का वर्तमान मूल्य है जिसे कुंजी-मूल्य जोड़े के मानचित्र के रूप में दर्शाया गया है। एक शर्त के भीतर resource को संदर्भित करने के परिणामस्वरूप सेवा से मूल्य का अधिकतम एक पढ़ा जाएगा। यह लुकअप संसाधन के लिए किसी भी सेवा-संबंधित कोटा के विरुद्ध गिना जाएगा। अनुरोध get करने के लिए, resource केवल अस्वीकार किए जाने पर कोटा में गिना जाएगा।

ऑपरेटरों और ऑपरेटर पूर्वता

क्लाउड फायरस्टोर और क्लाउड स्टोरेज के नियमों में ऑपरेटरों और उनकी संबंधित प्राथमिकता के संदर्भ के रूप में नीचे दी गई तालिका का उपयोग करें।

मनमाना व्यंजक a और b , एक फ़ील्ड f , और एक अनुक्रमणिका i दिया गया है।

ऑपरेटर विवरण संबद्धता
a[i] a() af इंडेक्स, कॉल, फील्ड एक्सेस बाएं से दायां
!a -a एकात्मक निषेध दाएं से बाएं
a/ba%ba*b गुणक संचालिका बाएं से दायां
a+b ab योजक ऑपरेटर बाएं से दायां
a>ba>=ba संबंधपरक संकारक बाएं से दायां
a in b सूची या मानचित्र में अस्तित्व बाएं से दायां
a is type तुलना टाइप करें, जहां type बूल, इंट, फ्लोट, संख्या, स्ट्रिंग, सूची, मानचित्र, टाइमस्टैम्प, अवधि, पथ या अक्षांश हो सकता है बाएं से दायां
a==ba!=b तुलना ऑपरेटर बाएं से दायां
a && b सशर्त और बाएं से दायां
a || b सशर्त OR बाएं से दायां
a ? true_value : false_value टर्नरी एक्सप्रेशन बाएं से दायां

घन संग्रहण

एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या अस्वीकार की जानी चाहिए। request और resource चर उन स्थितियों के लिए संदर्भ प्रदान करते हैं।

request चर

request चर में निम्नलिखित फ़ील्ड और संबंधित जानकारी शामिल है:

request.auth

एक JSON वेब टोकन (JWT) जिसमें Firebase प्रमाणीकरण से प्रमाणीकरण क्रेडेंशियल शामिल हैं। auth टोकन में मानक दावों का एक सेट और आपके द्वारा Firebase प्रमाणीकरण के माध्यम से बनाए गए सभी कस्टम दावे शामिल होते हैं। Firebase सुरक्षा नियमों और प्रमाणीकरण के बारे में अधिक जानें।

request.method

request.method कोई भी मानक विधि या कस्टम विधि हो सकती है। read और write की सुविधा विधियाँ लेखन नियमों को सरल बनाने के लिए भी मौजूद हैं जो क्रमशः सभी-पढ़ने के लिए या सभी केवल-लिखने के मानक तरीकों पर लागू होते हैं।

request.params

request.params में कोई भी डेटा शामिल है जो विशेष रूप से request.resource से संबंधित नहीं है जो मूल्यांकन के लिए उपयोगी हो सकता है। व्यवहार में, यह नक्शा सभी मानक विधियों के लिए खाली होना चाहिए, और इसमें कस्टम विधियों के लिए गैर-संसाधन डेटा होना चाहिए। सेवाओं को सावधान रहना चाहिए कि पैरा के रूप में प्रस्तुत किसी भी कुंजी और मूल्यों के प्रकार का नाम बदलें या संशोधित न करें।

request.path

request.path लक्ष्य resource के लिए पथ है। पथ सेवा के सापेक्ष है। गैर-यूआरएल सुरक्षित वर्णों वाले पथ खंड जैसे / यूआरएल-एन्कोडेड हैं।

resource चर

resource सेवा के भीतर का वर्तमान मूल्य है जिसे कुंजी-मूल्य जोड़े के मानचित्र के रूप में दर्शाया गया है। एक शर्त के भीतर resource को संदर्भित करने के परिणामस्वरूप सेवा से मूल्य का अधिकतम एक पढ़ा जाएगा। यह लुकअप संसाधन के लिए किसी भी सेवा-संबंधित कोटा के विरुद्ध गिना जाएगा। अनुरोध get करने के लिए, resource केवल अस्वीकार किए जाने पर कोटा में गिना जाएगा।

ऑपरेटरों और ऑपरेटर पूर्वता

क्लाउड फायरस्टोर और क्लाउड स्टोरेज के नियमों में ऑपरेटरों और उनकी संबंधित प्राथमिकता के संदर्भ के रूप में नीचे दी गई तालिका का उपयोग करें।

मनमाना व्यंजक a और b , एक फ़ील्ड f , और एक अनुक्रमणिका i दिया गया है।

ऑपरेटर विवरण संबद्धता
a[i] a() af इंडेक्स, कॉल, फील्ड एक्सेस बाएं से दायां
!a -a एकात्मक निषेध दाएं से बाएं
a/ba%ba*b गुणक संचालिका बाएं से दायां
a+b ab योजक ऑपरेटर बाएं से दायां
a>ba>=ba संबंधपरक संकारक बाएं से दायां
a in b सूची या मानचित्र में अस्तित्व बाएं से दायां
a is type तुलना टाइप करें, जहां type बूल, इंट, फ्लोट, संख्या, स्ट्रिंग, सूची, मानचित्र, टाइमस्टैम्प, अवधि, पथ या अक्षांश हो सकता है बाएं से दायां
a==ba!=b तुलना ऑपरेटर बाएं से दायां
a && b सशर्त और बाएं से दायां
a || b सशर्त OR बाएं से दायां
a ? true_value : false_value टर्नरी एक्सप्रेशन बाएं से दायां

रीयलटाइम डेटाबेस

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

पूर्व-निर्धारित चर

कई उपयोगी, पूर्व-निर्धारित चर हैं जिन्हें एक नियम परिभाषा के भीतर पहुँचा जा सकता है। यहां प्रत्येक का संक्षिप्त सारांश दिया गया है:

पूर्वनिर्धारित चर
अभी व लिनक्स युग के बाद से मिलीसेकंड में वर्तमान समय। यह एसडीके के firebase.database.ServerValue.TIMESTAMP के साथ बनाए गए टाइमस्टैम्प को मान्य करने के लिए विशेष रूप से अच्छी तरह से काम करता है।
जड़ एक नियमडेटा स्नैपशॉट जो फायरबेस डेटाबेस में रूट पथ का प्रतिनिधित्व करता है क्योंकि यह प्रयास किए गए ऑपरेशन से पहले मौजूद है।
नए आंकड़े एक नियमडेटा स्नैपशॉट डेटा का प्रतिनिधित्व करता है क्योंकि यह प्रयास किए गए ऑपरेशन के बाद मौजूद होगा। इसमें लिखा जा रहा नया डेटा और मौजूदा डेटा शामिल है।
जानकारी एक नियमडेटा स्नैपशॉट डेटा का प्रतिनिधित्व करता है क्योंकि यह प्रयास किए गए ऑपरेशन से पहले मौजूद था।
$ चर एक वाइल्डकार्ड पथ जिसका उपयोग आईडी और डायनेमिक चाइल्ड कुंजियों का प्रतिनिधित्व करने के लिए किया जाता है।
प्रमाणन एक प्रमाणित उपयोगकर्ता के टोकन पेलोड का प्रतिनिधित्व करता है।

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

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

डेटा-आधारित नियम

आपके डेटाबेस के किसी भी डेटा का उपयोग आपके नियमों में किया जा सकता है। पूर्वनिर्धारित चर root , data और newData का उपयोग करके, आप किसी भी पथ तक पहुंच सकते हैं क्योंकि यह एक लेखन घटना से पहले या बाद में मौजूद होगा।

इस उदाहरण पर विचार करें, जो लिखने के संचालन की अनुमति देता है जब तक कि / readOnly /allow_writes/ नोड का मान true , मूल नोड में केवल पढ़ने के लिए ध्वज सेट नहीं है, और नए लिखित डेटा में foo नाम का एक बच्चा है:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

प्रश्न-आधारित नियम

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

उदाहरण के लिए, निम्न क्वेरी-आधारित नियम उपयोगकर्ता-आधारित सुरक्षा नियमों और क्वेरी-आधारित नियमों का उपयोग करता है, ताकि baskets संग्रह में डेटा तक पहुंच को केवल सक्रिय उपयोगकर्ता के स्वामित्व वाले शॉपिंग बास्केट तक सीमित किया जा सके:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

निम्नलिखित क्वेरी, जिसमें नियम में क्वेरी पैरामीटर शामिल हैं, सफल होंगी:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

हालांकि, नियम में पैरामीटर शामिल नहीं करने वाली क्वेरी PermissionDenied त्रुटि के साथ विफल हो जाएंगी:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

आप क्वेरी-आधारित नियमों का उपयोग यह सीमित करने के लिए भी कर सकते हैं कि क्लाइंट रीड ऑपरेशंस के माध्यम से कितना डेटा डाउनलोड करता है।

उदाहरण के लिए, निम्न नियम प्राथमिकता के क्रम में किसी क्वेरी के केवल पहले 1000 परिणामों तक पढ़ने की पहुंच को सीमित करता है:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

निम्नलिखित query. अभिव्यक्ति रीयलटाइम डेटाबेस नियमों में उपलब्ध हैं।

प्रश्न-आधारित नियम व्यंजक
अभिव्यक्ति टाइप विवरण
query.orderByKey
query.orderByPriority
query.orderByValue
बूलियन कुंजी, प्राथमिकता या मान के आधार पर ऑर्डर की गई क्वेरी के लिए सही है। अन्यथा झूठा।
query.orderByChild डोरी
शून्य
चाइल्ड नोड के सापेक्ष पथ का प्रतिनिधित्व करने के लिए एक स्ट्रिंग का उपयोग करें। उदाहरण के लिए, query.orderByChild === "address/zip" । यदि चाइल्ड नोड द्वारा क्वेरी का आदेश नहीं दिया जाता है, तो यह मान शून्य है।
query.startAt
query.endAt
query.equalTo
डोरी
संख्या
बूलियन
शून्य
निष्पादन क्वेरी की सीमाओं को पुनः प्राप्त करता है, या यदि कोई बाध्य सेट नहीं है तो शून्य लौटाता है।
query.limitToFirst
query.limitToLast
संख्या
शून्य
निष्पादन क्वेरी पर सीमा को पुनः प्राप्त करता है, या यदि कोई सीमा निर्धारित नहीं है तो शून्य लौटाता है।

ऑपरेटर्स

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

स्थितियां बनाना

आप जिस एक्सेस को देना चाहते हैं, उसके आधार पर आपकी वास्तविक शर्तें अलग-अलग होंगी। नियम जानबूझकर बहुत अधिक लचीलेपन की पेशकश करते हैं, इसलिए आपके ऐप के नियम अंततः उतने ही सरल या उतने ही जटिल हो सकते हैं जितने की आपको उनकी आवश्यकता है।

सरल, उत्पादन के लिए तैयार नियम बनाने के लिए कुछ मार्गदर्शन के लिए, बुनियादी सुरक्षा नियम देखें।