क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियम आपको क्लाउड स्टोरेज बकेट में संग्रहीत वस्तुओं तक पहुंच को नियंत्रित करने की अनुमति देते हैं। लचीला नियम सिंटैक्स आपको किसी भी ऑपरेशन को नियंत्रित करने के लिए नियम बनाने की अनुमति देता है, सभी लिखने से लेकर आपके क्लाउड स्टोरेज बकेट तक किसी विशिष्ट फ़ाइल पर संचालन तक।
यह मार्गदर्शिका संपूर्ण नियम सेट बनाने के लिए क्लाउड स्टोरेज सुरक्षा नियमों के मूल सिंटैक्स और संरचना का वर्णन करती है।
सेवा और डेटाबेस घोषणा
क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियम हमेशा निम्नलिखित घोषणा के साथ शुरू होते हैं:
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
के परिणाम के अधीन है .
क्लाउड स्टोरेज सुरक्षा नियम कैस्केड नहीं होते हैं, और नियमों का मूल्यांकन केवल तभी किया जाता है जब अनुरोध पथ निर्दिष्ट नियमों के साथ पथ से मेल खाता हो।
संस्करण 1
फायरबेस सुरक्षा नियम डिफ़ॉल्ट रूप से संस्करण 1 का उपयोग करते हैं। संस्करण 1 में, पुनरावर्ती वाइल्डकार्ड एक या अधिक फ़ाइल नाम तत्वों से मेल खाते हैं, शून्य या अधिक तत्वों से नहीं। इस प्रकार, match /images/{filenamePrefixWildcard}/{imageFilename=**}
/images/profilePics/profile.png जैसे फ़ाइल नाम से मेल खाता है, लेकिन /images/badge.png से नहीं। इसके बजाय /images/{imagePrefixorFilename=**}
का उपयोग करें।
रिकर्सिव वाइल्डकार्ड मैच स्टेटमेंट के अंत में आने चाहिए।
हम अनुशंसा करते हैं कि आप इसकी अधिक शक्तिशाली विशेषताओं के लिए संस्करण 2 का उपयोग करें।
संस्करण 2
फायरबेस सुरक्षा नियमों के संस्करण 2 में, पुनरावर्ती वाइल्डकार्ड शून्य या अधिक पथ आइटम से मेल खाते हैं। इस प्रकार, /images/{filenamePrefixWildcard}/{imageFilename=**}
फ़ाइल नाम /images/profilePics/profile.png और /images/badge.png से मेल खाता है।
आपको rules_version = '2';
आपके सुरक्षा नियमों के शीर्ष पर:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
आपके पास प्रति मैच स्टेटमेंट में अधिकतम एक रिकर्सिव वाइल्डकार्ड हो सकता है, लेकिन संस्करण 2 में, आप इस वाइल्डकार्ड को मैच स्टेटमेंट में कहीं भी रख सकते हैं। उदाहरण के लिए:
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 document 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 nonexistent files allow create: if <condition>; // Applies to updates to 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 any filename containing string '/images/'.
match /images/{imageId} {
allow read, write: if false;
}
// Matches all filenames containing string `/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';
}
}
}
अस्वीकृत : यह नियम निम्नलिखित अनुरोध को अस्वीकार करता है क्योंकि परिणाम सेट में वे फ़ाइलें शामिल हो सकती हैं जहां सामग्री प्रकार image/png
contentType
है:
वेब
filesRef = storage.ref().child("aFilenamePrefix"); filesRef.listAll() .then(function(result) { console.log("Success: ", result.items); }) });
क्लाउड स्टोरेज सुरक्षा नियमों के नियम प्रत्येक क्वेरी का उसके संभावित परिणाम के विरुद्ध मूल्यांकन करते हैं और अनुरोध को विफल कर देते हैं यदि वह ऐसी फ़ाइल लौटा सकता है जिसे पढ़ने के लिए क्लाइंट के पास अनुमति नहीं है। एक्सेस अनुरोधों को आपके नियमों द्वारा निर्धारित बाधाओं का पालन करना चाहिए।
अगले कदम
आप क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियमों की अपनी समझ को गहरा कर सकते हैं:
नियम भाषा की अगली प्रमुख अवधारणा जानें, गतिशील स्थितियां , जो आपके नियमों को उपयोगकर्ता प्राधिकरण की जांच करने, मौजूदा और आने वाले डेटा की तुलना करने, आने वाले डेटा को मान्य करने, और बहुत कुछ करने देती हैं।
विशिष्ट सुरक्षा उपयोग के मामलों और उन्हें संबोधित करने वाले फायरबेस सुरक्षा नियमों की परिभाषाओं की समीक्षा करें।
आप Firebase सुरक्षा नियम क्लाउड स्टोरेज के लिए विशिष्ट मामलों का उपयोग कर सकते हैं: