क्लाउड स्टोरेज भाषा के लिए फायरबेस सुरक्षा नियमों का मुख्य सिंटैक्स सीखें

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

यह मार्गदर्शिका संपूर्ण नियमसेट बनाने के लिए क्लाउड स्टोरेज सुरक्षा नियमों के मूल सिंटैक्स और संरचना का वर्णन करती है।

सेवा और डेटाबेस घोषणा

क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियम हमेशा निम्नलिखित घोषणा से शुरू होते हैं:

service firebase.storage {
    // ...
}

service firebase.storage घोषणा क्लाउड स्टोरेज के नियमों को सीमित करती है, जिससे क्लाउड स्टोरेज सुरक्षा नियमों और क्लाउड फ़ायरस्टोर जैसे अन्य उत्पादों के नियमों के बीच टकराव को रोका जा सकता है।

बुनियादी पढ़ने/लिखने के नियम

बुनियादी नियमों में क्लाउड स्टोरेज बकेट की पहचान करने वाला एक match स्टेटमेंट, एक फ़ाइल नाम निर्दिष्ट करने वाला एक मैच स्टेटमेंट और निर्दिष्ट डेटा को पढ़ने की अनुमति देते समय विवरण देने वाला एक allow अभिव्यक्ति शामिल है। allow अभिव्यक्ति में शामिल पहुंच विधियों (उदाहरण के लिए, पढ़ना, लिखना) और उन शर्तों को निर्दिष्ट करें जिनके तहत पहुंच की अनुमति दी जाती है या अस्वीकार की जाती है।

आपके डिफ़ॉल्ट नियमसेट में, पहला match विवरण आपके प्रोजेक्ट में सभी बकेट पर लागू होने वाले नियमों को इंगित करने के लिए एक {bucket} वाइल्डकार्ड अभिव्यक्ति का उपयोग करता है। हम अगले भाग में वाइल्डकार्ड मैचों के विचार पर अधिक चर्चा करेंगे।

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

सभी मिलान विवरण फाइलों की ओर इशारा करते हैं। एक मिलान विवरण एक विशिष्ट फ़ाइल को इंगित कर सकता है, जैसे कि match /images/profilePhoto.png में।

वाइल्डकार्ड का मिलान करें

एकल फ़ाइल को इंगित करने के अलावा, नियम किसी भी फ़ाइल को उसके नाम में दिए गए स्ट्रिंग उपसर्ग के साथ इंगित करने के लिए वाइल्डकार्ड का उपयोग कर सकते हैं, जिसमें स्लैश भी शामिल हैं, जैसा कि match /images/{imageId} में होता है।

उपरोक्त उदाहरण में, मिलान विवरण {imageId} वाइल्डकार्ड सिंटैक्स का उपयोग करता है। इसका मतलब यह है कि नियम किसी भी फ़ाइल पर लागू होता है जिसके नाम की शुरुआत में /images/ है, जैसे /images/profilePhoto.png या /images/croppedProfilePhoto.png । जब मिलान विवरण में allow अभिव्यक्ति का मूल्यांकन किया जाता है, तो imageId वैरिएबल छवि फ़ाइल नाम, जैसे कि profilePhoto.png या croppedProfilePhoto.png को हल करेगा।

फ़ाइल नाम या पथ प्राधिकरण प्रदान करने के लिए एक वाइल्डकार्ड वैरिएबल को match के भीतर से संदर्भित किया जा सकता है:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

पदानुक्रमित डेटा

जैसा कि हमने पहले कहा, क्लाउड स्टोरेज बकेट के अंदर कोई पदानुक्रमित संरचना नहीं है। लेकिन फ़ाइल नामकरण परंपरा का उपयोग करके, जिसमें अक्सर फ़ाइल नाम में स्लैश शामिल होते हैं, हम एक ऐसी संरचना की नकल कर सकते हैं जो निर्देशिकाओं और उप-निर्देशिकाओं की नेस्टेड श्रृंखला की तरह दिखती है। यह समझना महत्वपूर्ण है कि फायरबेस सुरक्षा नियम इन फ़ाइल नामों के साथ कैसे इंटरैक्ट करते हैं।

उन फ़ाइलों के समूह की स्थिति पर विचार करें जिनके नाम /images/ स्टेम से शुरू होते हैं। फायरबेस सुरक्षा नियम केवल मिलान किए गए फ़ाइल नाम पर लागू होते हैं, इसलिए /images/ स्टेम पर परिभाषित एक्सेस नियंत्रण /mp3s/ स्टेम पर लागू नहीं होते हैं। इसके बजाय, स्पष्ट नियम लिखें जो विभिन्न फ़ाइल नाम पैटर्न से मेल खाते हों:

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

match विवरण को नेस्ट करते समय, आंतरिक match विवरण का पथ हमेशा बाहरी match विवरण के पथ से जोड़ा जाता है। इसलिए निम्नलिखित दो नियम समतुल्य हैं:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

पुनरावर्ती मिलान वाइल्डकार्ड

वाइल्डकार्ड के अलावा जो फ़ाइल नाम के अंत में स्ट्रिंग से मेल खाते हैं और लौटाते हैं, वाइल्डकार्ड नाम में =** जोड़कर अधिक जटिल मिलान के लिए एक मल्टीपल सेगमेंट वाइल्डकार्ड घोषित किया जा सकता है, जैसे कि {path=**} :

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

यदि एकाधिक नियम किसी फ़ाइल से मेल खाते हैं, तो परिणाम सभी नियमों के मूल्यांकन के परिणाम का OR है। अर्थात्, यदि फ़ाइल का कोई भी नियम true से मेल खाता है, तो परिणाम true है।

उपरोक्त नियमों में, फ़ाइल "images/profilePhoto.png" को पढ़ा जा सकता है यदि कोई भी condition या other_condition सत्य का मूल्यांकन करती है, जबकि फ़ाइल "images/users/user:12345/profilePhoto.png" केवल other_condition के परिणाम के अधीन है .

क्लाउड स्टोरेज सुरक्षा नियम कैस्केड नहीं होते हैं, और नियमों का मूल्यांकन केवल तभी किया जाता है जब अनुरोध पथ निर्दिष्ट नियमों के साथ पथ से मेल खाता है।

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

दानेदार संचालन

कुछ स्थितियों में, read और write अधिक विस्तृत संचालन में विभाजित करना उपयोगी होता है। उदाहरण के लिए, आपका ऐप फ़ाइल हटाने की तुलना में फ़ाइल निर्माण पर भिन्न शर्तें लागू करना चाह सकता है।

एक read ऑपरेशन को get और list में तोड़ा जा सकता है।

एक write नियम को create , update और delete में तोड़ा जा सकता है:

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

ओवरलैपिंग मिलान विवरण

किसी फ़ाइल नाम का एक से अधिक match विवरण से मेल खाना संभव है। ऐसे मामले में जहां एकाधिक allow अभिव्यक्तियां एक अनुरोध से मेल खाती हैं, यदि कोई भी शर्त true है तो पहुंच की अनुमति दी जाती है:

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

उपरोक्त उदाहरण में, उन सभी फ़ाइलों को पढ़ने और लिखने की अनुमति है जिनका नाम /images/ से शुरू होता है क्योंकि दूसरा नियम हमेशा true है, भले ही पहला नियम false हो।

नियम फ़िल्टर नहीं हैं

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

उदाहरण के लिए, निम्नलिखित सुरक्षा नियम लें:

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

अस्वीकृत : यह नियम निम्नलिखित अनुरोध को अस्वीकार करता है क्योंकि परिणाम सेट में वे फ़ाइलें शामिल हो सकती हैं जहां contentType image/png नहीं है:

filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

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

अगले कदम

आप क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियमों की अपनी समझ को गहरा कर सकते हैं:

• नियम भाषा की अगली प्रमुख अवधारणा, गतिशील स्थितियाँ सीखें, जो आपके नियमों को उपयोगकर्ता प्राधिकरण की जाँच करने, मौजूदा और आने वाले डेटा की तुलना करने, आने वाले डेटा को सत्यापित करने और बहुत कुछ करने देती हैं।

• विशिष्ट सुरक्षा उपयोग मामलों और उन्हें संबोधित करने वाली फ़ायरबेस सुरक्षा नियम परिभाषाओं की समीक्षा करें।

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