फायरबेस क्लाउड स्टोरेज सुरक्षा नियमों में उपयोग की शर्तें

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

क्लाउड स्टोरेज सुरक्षा नियमों का प्राथमिक बिल्डिंग ब्लॉक शर्त है। एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या अस्वीकार किया जाना चाहिए। बुनियादी नियमों के लिए, शर्तों के रूप में true और false अक्षर का उपयोग करना पूरी तरह से अच्छी तरह से काम करता है। लेकिन क्लाउड स्टोरेज भाषा के लिए फायरबेस सुरक्षा नियम आपको अधिक जटिल स्थितियों को लिखने के तरीके प्रदान करते हैं:

  • उपयोगकर्ता प्रमाणीकरण की जाँच करें
  • आने वाले डेटा को मान्य करें

प्रमाणीकरण

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

जब एक प्रमाणित उपयोगकर्ता क्लाउड स्टोरेज के खिलाफ अनुरोध करता है, तो request.auth वैरिएबल उपयोगकर्ता के uid ( request.auth.uid ) के साथ-साथ फायरबेस प्रमाणीकरण JWT ( request.auth.token ) के दावों से भर जाता है।

इसके अतिरिक्त, कस्टम प्रमाणीकरण का उपयोग करते समय, अतिरिक्त दावे request.auth.token फ़ील्ड में सामने आते हैं।

जब कोई अप्रमाणित उपयोगकर्ता अनुरोध करता है, तो request.auth वैरिएबल null है।

इस डेटा का उपयोग करके, फ़ाइलों को सुरक्षित करने के लिए प्रमाणीकरण का उपयोग करने के कई सामान्य तरीके हैं:

  • सार्वजनिक: request.auth अनदेखा करें
  • प्रमाणित निजी: जांचें कि request.auth null नहीं है
  • उपयोगकर्ता निजी: जांचें कि request.auth.uid एक पथ uid के बराबर है
  • समूह निजी: किसी चुने गए दावे से मेल खाने के लिए कस्टम टोकन के दावों की जांच करें, या मेटाडेटा फ़ील्ड मौजूद है या नहीं यह देखने के लिए फ़ाइल मेटाडेटा पढ़ें

जनता

कोई भी नियम जो request.auth संदर्भ पर विचार नहीं करता है उसे public नियम माना जा सकता है, क्योंकि यह उपयोगकर्ता के प्रमाणीकरण संदर्भ पर विचार नहीं करता है। ये नियम सार्वजनिक डेटा जैसे गेम संपत्ति, ध्वनि फ़ाइलें, या अन्य स्थिर सामग्री को सामने लाने के लिए उपयोगी हो सकते हैं।

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

प्रमाणित निजी

कुछ मामलों में, आप चाहते हैं कि डेटा आपके एप्लिकेशन के सभी प्रमाणित उपयोगकर्ताओं द्वारा देखा जा सके, लेकिन अप्रमाणित उपयोगकर्ताओं द्वारा नहीं। चूंकि सभी अप्रमाणित उपयोगकर्ताओं के लिए request.auth वैरिएबल null है, इसलिए आपको केवल यह जांचना होगा कि प्रमाणीकरण की आवश्यकता के लिए request.auth वैरिएबल मौजूद है:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

उपयोगकर्ता निजी

request.auth के लिए अब तक का सबसे आम उपयोग मामला व्यक्तिगत उपयोगकर्ताओं को उनकी फ़ाइलों पर विस्तृत अनुमतियाँ प्रदान करना होगा: प्रोफ़ाइल चित्र अपलोड करने से लेकर निजी दस्तावेज़ पढ़ने तक।

चूँकि क्लाउड स्टोरेज में फ़ाइलों के पास फ़ाइल के लिए एक पूर्ण "पथ" होता है, उपयोगकर्ता द्वारा नियंत्रित फ़ाइल बनाने के लिए फ़ाइल नाम उपसर्ग में अद्वितीय, उपयोगकर्ता की पहचान करने वाली जानकारी का एक टुकड़ा होता है (जैसे कि उपयोगकर्ता का uid ) जिसे जांचा जा सकता है जब नियम का मूल्यांकन किया जाता है:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

समूह निजी

एक और समान रूप से सामान्य उपयोग का मामला किसी ऑब्जेक्ट पर समूह की अनुमति देना होगा, जैसे कि कई टीम सदस्यों को एक साझा दस्तावेज़ पर सहयोग करने की अनुमति देना। ऐसा करने के लिए कई दृष्टिकोण हैं:

  • एक फ़ायरबेस प्रमाणीकरण कस्टम टोकन बनाएं जिसमें समूह सदस्य (जैसे समूह आईडी) के बारे में अतिरिक्त जानकारी हो
  • फ़ाइल मेटाडेटा में समूह जानकारी (जैसे समूह आईडी या अधिकृत uid की सूची) शामिल करें

एक बार जब यह डेटा टोकन या फ़ाइल मेटाडेटा में संग्रहीत हो जाता है, तो इसे एक नियम के भीतर से संदर्भित किया जा सकता है:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

मूल्यांकन का अनुरोध करें

क्लाउड स्टोरेज को भेजे गए request उपयोग करके अपलोड, डाउनलोड, मेटाडेटा परिवर्तन और डिलीट का मूल्यांकन किया जाता है। जैसा कि ऊपर वर्णित है, request.auth ऑब्जेक्ट में उपयोगकर्ता की अद्वितीय आईडी और फ़ायरबेस प्रमाणीकरण पेलोड के अलावा, request चर में फ़ाइल पथ शामिल है जहां अनुरोध किया जा रहा है, अनुरोध प्राप्त होने का समय और नया resource मान शामिल है अनुरोध एक लेखन है.

request ऑब्जेक्ट में उपयोगकर्ता की विशिष्ट आईडी और request.auth ऑब्जेक्ट में फ़ायरबेस प्रमाणीकरण पेलोड भी शामिल है, जिसे दस्तावेज़ों के उपयोगकर्ता-आधारित सुरक्षा अनुभाग में आगे समझाया जाएगा।

request ऑब्जेक्ट में संपत्तियों की पूरी सूची नीचे उपलब्ध है:

संपत्ति प्रकार विवरण
auth मानचित्र<स्ट्रिंग, स्ट्रिंग> जब कोई उपयोगकर्ता लॉग इन होता है, तो uid , उपयोगकर्ता की विशिष्ट आईडी और token , फायरबेस प्रमाणीकरण जेडब्ल्यूटी दावों का एक मानचित्र प्रदान करता है। अन्यथा, यह null हो जाएगा.
params मानचित्र<स्ट्रिंग, स्ट्रिंग> मानचित्र जिसमें अनुरोध के क्वेरी पैरामीटर शामिल हैं।
path पथ एक path उस पथ का प्रतिनिधित्व करता है जिस पर अनुरोध निष्पादित किया जा रहा है।
resource मानचित्र<स्ट्रिंग, स्ट्रिंग> नया संसाधन मान, केवल write अनुरोधों पर मौजूद है।
time TIMESTAMP सर्वर समय का प्रतिनिधित्व करने वाला एक टाइमस्टैम्प जिस पर अनुरोध का मूल्यांकन किया जाता है।

संसाधन मूल्यांकन

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

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

write अनुरोधों (जैसे अपलोड, मेटाडेटा अपडेट और डिलीट) पर, resource ऑब्जेक्ट के अलावा, जिसमें वर्तमान में अनुरोध पथ पर मौजूद फ़ाइल के लिए फ़ाइल मेटाडेटा शामिल है, आपके पास request.resource ऑब्जेक्ट का उपयोग करने की क्षमता भी है। जिसमें लिखने की अनुमति होने पर लिखे जाने वाले फ़ाइल मेटाडेटा का एक सबसेट शामिल है। आप डेटा अखंडता सुनिश्चित करने या फ़ाइल प्रकार या आकार जैसी एप्लिकेशन बाधाओं को लागू करने के लिए इन दो मानों का उपयोग कर सकते हैं।

resource ऑब्जेक्ट में गुणों की पूरी सूची नीचे उपलब्ध है:

संपत्ति प्रकार विवरण
name डोरी वस्तु का पूरा नाम
bucket डोरी उस बकेट का नाम जिसमें यह ऑब्जेक्ट रहता है।
generation int यहाँ इस ऑब्जेक्ट की Google क्लाउड स्टोरेज ऑब्जेक्ट पीढ़ी
metageneration int यहाँ इस ऑब्जेक्ट का Google क्लाउड स्टोरेज ऑब्जेक्ट मेटाजेनरेशन
size int यहाँ ऑब्जेक्ट का आकार बाइट्स में.
timeCreated TIMESTAMP किसी ऑब्जेक्ट के निर्माण के समय का प्रतिनिधित्व करने वाला टाइमस्टैम्प।
updated TIMESTAMP किसी ऑब्जेक्ट को अंतिम बार अद्यतन किए जाने के समय का प्रतिनिधित्व करने वाला टाइमस्टैम्प।
md5Hash डोरी ऑब्जेक्ट का MD5 हैश.
crc32c डोरी ऑब्जेक्ट का crc32c हैश।
etag डोरी इस ऑब्जेक्ट से जुड़ा ईटैग.
contentDisposition डोरी इस वस्तु से संबद्ध सामग्री स्वभाव.
contentEncoding डोरी इस ऑब्जेक्ट से संबद्ध सामग्री एन्कोडिंग.
contentLanguage डोरी इस ऑब्जेक्ट से संबद्ध सामग्री भाषा.
contentType डोरी इस ऑब्जेक्ट से संबद्ध सामग्री प्रकार.
metadata मानचित्र<स्ट्रिंग, स्ट्रिंग> अतिरिक्त, डेवलपर द्वारा निर्दिष्ट कस्टम मेटाडेटा के कुंजी/मूल्य जोड़े।

request.resource generation , metageneration , etag , timeCreated और updated को छोड़कर ये सभी शामिल हैं।

क्लाउड फायरस्टोर के साथ सुधार करें

आप अन्य प्राधिकरण मानदंडों का मूल्यांकन करने के लिए क्लाउड फायरस्टोर में दस्तावेज़ों तक पहुंच सकते हैं।

firestore.get() और firestore.exists() फ़ंक्शंस का उपयोग करके, आपके सुरक्षा नियम क्लाउड फायरस्टोर में दस्तावेज़ों के विरुद्ध आने वाले अनुरोधों का मूल्यांकन कर सकते हैं। firestore.get() और firestore.exists() फ़ंक्शन दोनों पूरी तरह से निर्दिष्ट दस्तावेज़ पथ की अपेक्षा करते हैं। firestore.get() और firestore.exists() के लिए पथ बनाने के लिए वेरिएबल का उपयोग करते समय, आपको $(variable) सिंटैक्स का उपयोग करके वेरिएबल से स्पष्ट रूप से बचने की आवश्यकता होती है।

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

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{club}/files/{fileId} {
      allow read: if club in
        firestore.get(/databases/(default)/documents/users/$(request.auth.id)).memberships
    }
  }
}
अगले उदाहरण में, केवल उपयोगकर्ता के मित्र ही उनकी तस्वीरें देख सकते हैं।
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/photos/{fileId} {
      allow read: if
        firestore.exists(/databases/(default)/documents/users/$(userId)/friends/$(request.auth.id))
    }
  }
}

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

आप IAM भूमिका को हटाकर सुविधा को अक्षम कर सकते हैं, जैसा कि फायरबेस सुरक्षा नियमों को प्रबंधित और तैनात करने में वर्णित है।

डेटा सत्यापित करें

क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियमों का उपयोग डेटा सत्यापन के लिए भी किया जा सकता है, जिसमें फ़ाइल नाम और पथ के साथ-साथ contentType और size जैसे फ़ाइल मेटाडेटा गुणों को मान्य करना शामिल है।

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

कस्टम फ़ंक्शन

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

  • फ़ंक्शंस में केवल एक return स्टेटमेंट हो सकता है। उनमें कोई अतिरिक्त तर्क नहीं हो सकता. उदाहरण के लिए, वे लूप निष्पादित नहीं कर सकते या बाहरी सेवाओं को कॉल नहीं कर सकते।
  • फ़ंक्शंस स्वचालित रूप से फ़ंक्शंस और वेरिएबल्स को उस दायरे से एक्सेस कर सकते हैं जिसमें वे परिभाषित हैं। उदाहरण के लिए, service firebase.storage स्कोप के भीतर परिभाषित एक फ़ंक्शन के पास resource चर तक पहुंच होती है, और केवल क्लाउड फायरस्टोर के लिए, अंतर्निहित फ़ंक्शन जैसे get() और exists()
  • फ़ंक्शंस अन्य फ़ंक्शंस को कॉल कर सकते हैं लेकिन पुनरावृत्ति नहीं कर सकते। कुल कॉल स्टैक गहराई 10 तक सीमित है।
  • संस्करण rules2 में, फ़ंक्शन let कीवर्ड का उपयोग करके वेरिएबल्स को परिभाषित कर सकते हैं। फ़ंक्शंस में किसी भी संख्या में लेट बाइंडिंग हो सकती हैं, लेकिन उन्हें रिटर्न स्टेटमेंट के साथ समाप्त होना चाहिए।

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

service firebase.storage {
  match /b/{bucket}/o {
    // 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 /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

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

अगले कदम

शर्तों की इस चर्चा के बाद, आपको नियमों की अधिक परिष्कृत समझ मिल गई है और आप इसके लिए तैयार हैं:

जानें कि मुख्य उपयोग के मामलों को कैसे संभालना है, और नियमों के विकास, परीक्षण और तैनाती के लिए वर्कफ़्लो सीखें: