Google 致力于为黑人社区推动种族平等。查看具体举措

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

फायरबेस सुरक्षा नियम लचीली, शक्तिशाली, कस्टम भाषाओं का लाभ उठाते हैं जो जटिलता और ग्रैन्युलैरिटी की एक विस्तृत श्रृंखला का समर्थन करते हैं। आप अपने नियमों को उतना विशिष्ट या सामान्य बना सकते हैं जितना आपके ऐप के लिए उपयुक्त हो। रीयलटाइम डेटाबेस नियम एक सिंटैक्स का उपयोग करते हैं जो JSON संरचना में जावास्क्रिप्ट जैसा दिखता है। बादल Firestore और क्लाउड संग्रहण नियमों के आधार पर एक भाषा का प्रयोग आम अभिव्यक्ति भाषा (सीईएल) के साथ सीईएल पर आधारित है,, 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 एक या अधिक होता है match के साथ ब्लॉक allow बयान है कि अनुरोध करने के लिए पहुँच प्रदान करने की स्थिति प्रदान करते हैं। request और resource चर नियम की शर्तों में उपयोग के लिए उपलब्ध हैं। Firebase सुरक्षा नियमों भाषा भी समर्थन करता है function घोषणाओं।

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

syntax बयान स्रोत लिखने के लिए इस्तेमाल किया Firebase नियम भाषा के संस्करण इंगित करता है। भाषा का नवीनतम संस्करण है 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 ब्लॉक, allow बयान, या function घोषणाओं। नेस्टेड में पथ 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 बादल इस firestore या क्लाउड संग्रहण किसी भी भेजे इस अनुरोध को अस्वीकार करने के लिए बयान सही करने के लिए मूल्यांकन करना चाहिए। आप भी लिख सकते हैं 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 डेटा हटाएं

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

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

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 काम व्यवस्थापक संग्रह का एक देखने लागू करता है। अनावश्यक लुकअप की आवश्यकता के बिना आलसी मूल्यांकन के लिए, की शॉर्ट-सर्किट प्रकृति का लाभ लेने के && (और) और || (या) की तुलना में एक दूसरे समारोह केवल तभी कॉल करने के लिए 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 एक या अधिक होता है match के साथ ब्लॉक allow बयान है कि अनुरोध करने के लिए पहुँच प्रदान करने की स्थिति प्रदान करते हैं। request और resource चर नियम की शर्तों में उपयोग के लिए उपलब्ध हैं। Firebase सुरक्षा नियमों भाषा भी समर्थन करता है function घोषणाओं।

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

syntax बयान स्रोत लिखने के लिए इस्तेमाल किया Firebase नियम भाषा के संस्करण इंगित करता है। भाषा का नवीनतम संस्करण है 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 ब्लॉक, allow बयान, या function घोषणाओं। नेस्टेड में पथ 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 बादल इस firestore या क्लाउड संग्रहण किसी भी भेजे इस अनुरोध को अस्वीकार करने के लिए बयान सही करने के लिए मूल्यांकन करना चाहिए। आप भी लिख सकते हैं 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 डेटा हटाएं

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

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

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 काम व्यवस्थापक संग्रह का एक देखने लागू करता है। अनावश्यक लुकअप की आवश्यकता के बिना आलसी मूल्यांकन के लिए, की शॉर्ट-सर्किट प्रकृति का लाभ लेने के && (और) और || (या) की तुलना में एक दूसरे समारोह केवल तभी कॉल करने के लिए 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 नियम प्रकार डाटा संरचनाओं को लागू करता है प्रारूप और डेटा की सामग्री सत्यापित करता है। नियम चलाने .validate की पुष्टि करने के एक उसके बाद भी नियम .write नियम पहुंच देता है।

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

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

भवन की स्थिति

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

एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या अस्वीकार की जानी चाहिए। 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 । पथ सेवा के सापेक्ष है। जैसे गैर-यूआरएल सुरक्षित वर्ण युक्त पथ के सेगमेंट / url- एन्कोडेड है।

resource चर

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

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

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

मनमाना भाव को देखते हुए a और b , एक क्षेत्र f , और एक सूचकांक i

ऑपरेटर विवरण संबद्धता
a[i] a() af इंडेक्स, कॉल, फील्ड एक्सेस बाएं से दायां
!a -a एकात्मक निषेधneg दाएं से बाएं
a/ba%ba*b गुणक संचालिका बाएं से दायां
a+b ab योजक ऑपरेटर बाएं से दायां
a>ba>=ba संबंधपरक संकारक बाएं से दायां
a in b सूची या मानचित्र में अस्तित्व बाएं से दायां
a is type प्रकार तुलना, जहां type bool, int, नाव, संख्या, स्ट्रिंग, सूची, नक्शे, टाइमस्टैम्प, अवधि, पथ या हो सकता है LatLng बाएं से दायां
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 । पथ सेवा के सापेक्ष है। जैसे गैर-यूआरएल सुरक्षित वर्ण युक्त पथ के सेगमेंट / url- एन्कोडेड है।

resource चर

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

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

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

मनमाना भाव को देखते हुए a और b , एक क्षेत्र f , और एक सूचकांक i

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

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

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

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

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

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

इन चरों का उपयोग आपके नियमों में कहीं भी किया जा सकता है। उदाहरण के लिए, सुरक्षा नियमों नीचे है कि डेटा को पत्र लिखा सुनिश्चित /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 , आप किसी भी पथ के रूप में यह पहले या एक लिखने घटना के बाद मौजूद होगा पहुँच सकते हैं।

इस उदाहरण है, जो लंबे समय के रूप में लिखने के संचालन की अनुमति देता है पर विचार करें का मान के रूप में /allow_writes/ नोड है true , माता पिता के नोड एक भी नहीं है readOnly ध्वज सेट है, और वहाँ एक बच्चे को नामित किया गया है 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
संख्या
शून्य
निष्पादन क्वेरी पर सीमा को पुनः प्राप्त करता है, या यदि कोई सीमा निर्धारित नहीं है तो शून्य लौटाता है।

ऑपरेटर्स

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

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

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

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