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

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

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

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

request वस्तु में गुणों की पूरी सूची नीचे उपलब्ध है:

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

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

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

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

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

request.resource में generation , metageneration , etag , timeCreated , और updated के अपवाद के साथ ये सभी शामिल हैं।

डेटा मान्य करें

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

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

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

अगले कदम

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

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

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