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

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

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

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 और delete । read और write सुविधा विधियाँ निर्दिष्ट डेटाबेस या संग्रहण पथ पर व्यापक पढ़ने और लिखने की पहुँच को सक्षम करती हैं।
• पथ: डेटाबेस या संग्रहण स्थान, जिसे URI पथ के रूप में दर्शाया गया है।
• नियम: 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 और delete । read और write सुविधा विधियाँ निर्दिष्ट डेटाबेस या संग्रहण पथ पर व्यापक पढ़ने और लिखने की पहुँच को सक्षम करती हैं।
• पथ: डेटाबेस या संग्रहण स्थान, जिसे URI पथ के रूप में दर्शाया गया है।
• नियम: allow कथन, जिसमें एक शर्त शामिल है जो अनुरोध को अनुमति देती है यदि यह सत्य का मूल्यांकन करता है।

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

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

रीयलटाइम डेटाबेस में, फायरबेस सुरक्षा नियमों में JSON दस्तावेज़ में निहित जावास्क्रिप्ट जैसी अभिव्यक्तियाँ शामिल हैं।

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

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

नियम में तीन मूल तत्व हैं:

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

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

Cloud Firestore और Cloud Storage में एक नियम के मूल तत्व इस प्रकार हैं:

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

service में एक या एक से अधिक match ब्लॉक होते हैं जो allow बयानों के साथ होते हैं जो अनुरोधों तक पहुंच प्रदान करने वाली शर्तें प्रदान करते हैं। नियम शर्तों में उपयोग के लिए 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 ब्लॉक होने चाहिए, बयानों की 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 नियमों को एक या अधिक विधियों पर लागू कर सकते हैं। किसी आने वाले अनुरोध को स्वीकार करने के लिए Cloud Firestore या Cloud Storage के लिए 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 कथन में एक विधि शामिल होती है जो उसी विधि के आने वाले अनुरोधों के लिए पहुँच प्रदान करती है।

आप एक ही 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 असाइनमेंट व्यवस्थापक संग्रह के लुकअप को लागू करता है। अनावश्यक लुकअप की आवश्यकता के बिना आलसी मूल्यांकन के लिए, && (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);
}

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

घन संग्रहण

Cloud Firestore और Cloud Storage में एक नियम के मूल तत्व इस प्रकार हैं:

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

service में एक या एक से अधिक match ब्लॉक होते हैं जो allow बयानों के साथ होते हैं जो अनुरोधों तक पहुंच प्रदान करने वाली शर्तें प्रदान करते हैं। नियम शर्तों में उपयोग के लिए 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 ब्लॉक होने चाहिए, बयानों की 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 नियमों को एक या अधिक विधियों पर लागू कर सकते हैं। किसी आने वाले अनुरोध को स्वीकार करने के लिए Cloud Firestore या Cloud Storage के लिए 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 कथन में एक विधि शामिल होती है जो उसी विधि के आने वाले अनुरोधों के लिए पहुँच प्रदान करती है।

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

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

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

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

request चर

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

request.auth

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

request.method

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

request.params

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

request.path

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

resource चर

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

ऑपरेटरों और ऑपरेटर प्राथमिकता

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

दिए गए मनमाने भाव a और b , एक क्षेत्र f , और एक सूचकांक i ।

घन संग्रहण

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

request चर

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

request.auth

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

request.method

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

request.params

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

request.path

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

resource चर

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

ऑपरेटरों और ऑपरेटर प्राथमिकता

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

दिए गए मनमाने भाव a और b , एक क्षेत्र f , और एक सूचकांक i ।

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

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

पूर्व परिभाषित चर

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

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

ऑपरेटर्स

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