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

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

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

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

प्रमाणीकरण

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

जब एक प्रमाणित उपयोगकर्ता क्लाउड स्टोरेज के खिलाफ अनुरोध करता है, तो request.auth चर उपयोगकर्ता के uid ( request.auth.uid ) के साथ-साथ फायरबेस ऑथेंटिकेशन जेडब्ल्यूटी ( 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() फ़ंक्शंस का उपयोग करके, आपके सुरक्षा नियम Cloud Firestore में दस्तावेज़ों के विरुद्ध आने वाले अनुरोधों का मूल्यांकन कर सकते हैं। 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 भूमिका को हटाकर सुविधा को अक्षम कर सकते हैं, जैसा कि Firebase सुरक्षा नियम प्रबंधित और परिनियोजित करें में बताया गया है।

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

क्लाउड स्टोरेज के लिए फायरबेस सुरक्षा नियमों का उपयोग डेटा सत्यापन के लिए भी किया जा सकता है, जिसमें फ़ाइल नाम और पथ के साथ-साथ फ़ाइल मेटाडेटा गुण जैसे 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/.*');
    }
  }
}

कस्टम कार्य

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

• फ़ंक्शंस में केवल एक 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();
    }
  }
}

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

अगले कदम

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

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

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