Firebase Security Rules की मदद से, Cloud Storage बकेट में सेव किए गए ऑब्जेक्ट के ऐक्सेस को कंट्रोल किया जा सकता है.Cloud Storage नियमों के फ़्लेक्सिबल सिंटैक्स की मदद से, नियम बनाए जा सकते हैं. इन नियमों से, बकेट में सभी तरह के राइट ऐक्सेस को कंट्रोल किया जा सकता है. साथ ही, किसी खास फ़ाइल पर की जाने वाली कार्रवाइयों को भी कंट्रोल किया जा सकता है.Cloud Storage
इस गाइड में, Cloud Storage Security Rules के बुनियादी सिंटैक्स और स्ट्रक्चर के बारे में बताया गया है. इसकी मदद से, नियमों के पूरे सेट बनाए जा सकते हैं.
सेवा और डेटाबेस का एलान
Firebase Security Rules के लिए Cloud Storage हमेशा इस एलान से शुरू होते हैं:
service firebase.storage {
// ...
}
The service firebase.storage एलान, नियमों को
Cloud Storage तक सीमित करता है. इससे, Cloud Storage Security Rules और
Cloud Firestore जैसे अन्य प्रॉडक्ट के नियमों के बीच टकराव नहीं होता.
पढ़ने/लिखने के बुनियादी नियम
बुनियादी नियमों में, एक match स्टेटमेंट शामिल होता है. यह स्टेटमेंट, Cloud Storage
बकेट की पहचान करता है. इसमें एक मैच स्टेटमेंट होता है, जो फ़ाइल का नाम तय करता है. साथ ही, इसमें एक 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.
वाइल्डकार्ड मैच करें
Security Rules, किसी एक फ़ाइल की ओर इशारा करने के अलावा, Security Rules वाइल्डकार्ड का इस्तेमाल करके, किसी भी ऐसी फ़ाइल की ओर इशारा कर सकते हैं जिसके नाम में, स्लैश के साथ कोई स्ट्रिंग प्रीफ़िक्स दिया गया हो. जैसे, 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";
}
क्रम के हिसाब से व्यवस्थित डेटा
जैसा कि हमने पहले बताया था कि a Cloud Storage बकेट में, क्रम के हिसाब से व्यवस्थित कोई स्ट्रक्चर नहीं होता. हालांकि, फ़ाइल नेमिंग कन्वेंशन का इस्तेमाल करके, हम ऐसा स्ट्रक्चर बना सकते हैं जो डायरेक्ट्री और सब-डायरेक्ट्री की नेस्ट की गई सीरीज़ की तरह दिखता है. इसके लिए, अक्सर फ़ाइल नामों में स्लैश शामिल किए जाते हैं. यह समझना ज़रूरी है कि Firebase Security Rules इन फ़ाइल नामों के साथ कैसे इंटरैक्ट करते हैं.
मान लें कि आपके पास फ़ाइलों का एक सेट है. इन सभी फ़ाइलों के नाम, /images/ से शुरू होते हैं. Firebase Security Rules सिर्फ़ मैच किए गए फ़ाइल नाम पर लागू होते हैं. इसलिए, /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 का नतीजा लागू होता है.
Cloud Storage Security Rules एक के बाद एक लागू नहीं होते. नियमों का आकलन सिर्फ़ तब किया जाता है, जब अनुरोध का पाथ, नियमों के साथ तय किए गए पाथ से मैच करता है.
वर्शन 1
Firebase Security Rules डिफ़ॉल्ट रूप से वर्शन 1 का इस्तेमाल करते हैं. वर्शन 1 में, बार-बार लागू होने वाले वाइल्डकार्ड, फ़ाइल नाम के एक या उससे ज़्यादा एलिमेंट से मैच करते हैं. ये शून्य या उससे ज़्यादा एलिमेंट से मैच नहीं करते. इसलिए, match /images/{filenamePrefixWildcard}/{imageFilename=**} , /images/profilePics/profile.png जैसे फ़ाइल नाम से मैच करता है, लेकिन /images/badge.png से नहीं. इसके बजाय, /images/{imagePrefixorFilename=**} का इस्तेमाल करें.
बार-बार लागू होने वाले वाइल्डकार्ड, मैच स्टेटमेंट के आखिर में होने चाहिए.
हमारा सुझाव है कि आप वर्शन 2 का इस्तेमाल करें, क्योंकि इसमें ज़्यादा बेहतर सुविधाएं मिलती हैं.
वर्शन 2
Firebase Security Rules के वर्शन 2 में, बार-बार लागू होने वाले वाइल्डकार्ड, शून्य या उससे ज़्यादा पाथ
आइटम से मैच करते हैं. इसलिए, /images/{filenamePrefixWildcard}/{imageFilename=**} , /images/profilePics/profile.png और /images/badge.png जैसे फ़ाइल नामों से मैच करता है.
वर्शन 2 को चुनने के लिए, आपको अपनी सुरक्षा से जुड़े नियमों में सबसे ऊपर 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 file read requests allow get: if <condition>; // Applies to list and listAll requests (Security 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 हो.
नियम, फ़िल्टर नहीं होते
डेटा को सुरक्षित करने और फ़ाइल से जुड़ी कार्रवाइयां करने के बाद, इस बात का ध्यान रखें कि सुरक्षा से जुड़े नियम, फ़िल्टर नहीं होते. फ़ाइल नाम के पैटर्न से मैच करने वाली फ़ाइलों के सेट पर कार्रवाइयां नहीं की जा सकतीं. साथ ही, यह उम्मीद नहीं की जा सकती कि Cloud Storage सिर्फ़ उन फ़ाइलों को ऐक्सेस करेगा जिन्हें मौजूदा क्लाइंट को ऐक्सेस करने की अनुमति है.
उदाहरण के लिए, सुरक्षा से जुड़ा यह नियम देखें:
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); }) });
Cloud Storage Security Rules में, हर क्वेरी का आकलन उसके संभावित नतीजे के हिसाब से किया जाता है. अगर क्वेरी से ऐसी फ़ाइल मिल सकती है जिसे क्लाइंट को पढ़ने की अनुमति नहीं है, तो अनुरोध को अस्वीकार कर दिया जाता है. ऐक्सेस के अनुरोध, आपके नियमों में तय की गई पाबंदियों के मुताबिक होने चाहिए.
अगले चरण
Cloud Storage के लिए Firebase Security Rules के बारे में ज़्यादा जानकारी पाई जा सकती है:
नियमों की भाषा के अगले अहम कॉन्सेप्ट, डाइनैमिक शर्तों के बारे में जानें. इनकी मदद से, आपके नियम, उपयोगकर्ता की अनुमति की जांच कर सकते हैं, मौजूदा और आने वाले डेटा की तुलना कर सकते हैं, आने वाले डेटा की पुष्टि कर सकते हैं वगैरह.
सुरक्षा से जुड़े सामान्य इस्तेमाल के उदाहरण और उन्हें हल करने के लिए, Firebase Security Rules परिभाषाएं देखें.
Firebase Security Rules के इस्तेमाल के उदाहरण देखे जा सकते हैं: Cloud Storage