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

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

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

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

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

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

• service घोषणा: उस फ़ायरबेस उत्पाद की घोषणा करती है जिस पर नियम लागू होते हैं।
• 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 घोषणा परिभाषित करती है कि आपके नियम किस फायरबेस उत्पाद या सेवा पर लागू होते हैं। आप प्रति स्रोत फ़ाइल में केवल एक 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
}

यदि आप फायरबेस सीएलआई का उपयोग करके क्लाउड फायरस्टोर और क्लाउड स्टोरेज दोनों के लिए नियम परिभाषित कर रहे हैं, तो आपको उन्हें अलग-अलग फाइलों में बनाए रखना होगा।

मिलान

एक 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 विवरण की शर्तों का मूल्यांकन सही होना चाहिए। आप बिना किसी शर्त के भी allow कथन लिख सकते हैं, उदाहरण के लिए, allow read । हालाँकि, यदि allow कथन में कोई शर्त शामिल नहीं है, तो यह हमेशा उस पद्धति के लिए अनुरोध की अनुमति देता है।

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

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

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);
}

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

घन संग्रहण

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

• service घोषणा: उस फ़ायरबेस उत्पाद की घोषणा करती है जिस पर नियम लागू होते हैं।
• 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 घोषणा परिभाषित करती है कि आपके नियम किस फायरबेस उत्पाद या सेवा पर लागू होते हैं। आप प्रति स्रोत फ़ाइल में केवल एक 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
}

यदि आप फायरबेस सीएलआई का उपयोग करके क्लाउड फायरस्टोर और क्लाउड स्टोरेज दोनों के लिए नियम परिभाषित कर रहे हैं, तो आपको उन्हें अलग-अलग फाइलों में बनाए रखना होगा।

मिलान

एक 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 विवरण की शर्तों का मूल्यांकन सही होना चाहिए। आप बिना किसी शर्त के भी allow कथन लिख सकते हैं, उदाहरण के लिए, allow read । हालाँकि, यदि allow कथन में कोई शर्त शामिल नहीं है, तो यह हमेशा उस पद्धति के लिए अनुरोध की अनुमति देता है।

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

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

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

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

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

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

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 के लिए पथ है। पथ सेवा से संबंधित है. गैर-यूआरएल सुरक्षित वर्ण जैसे / वाले पथ खंड यूआरएल-एन्कोडेड हैं।

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. अभिव्यक्तियाँ रीयलटाइम डेटाबेस सुरक्षा नियमों में उपलब्ध हैं।

ऑपरेटर्स

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