यह मार्गदर्शिका क्लाउड स्टोरेज के लिए अपने फायरबेस सुरक्षा नियमों में शर्तों को जोड़ने का तरीका दिखाने के लिए फायरबेस सुरक्षा नियम भाषा गाइड के मूल सिंटैक्स को सीखने पर आधारित है।
क्लाउड स्टोरेज सुरक्षा नियमों का प्राथमिक बिल्डिंग ब्लॉक शर्त है। एक शर्त एक बूलियन अभिव्यक्ति है जो यह निर्धारित करती है कि किसी विशेष ऑपरेशन की अनुमति दी जानी चाहिए या अस्वीकार किया जाना चाहिए। बुनियादी नियमों के लिए, शर्तों के रूप में 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();
}
}
}
जैसे-जैसे आपके नियमों की जटिलता बढ़ती है, आपके फायरबेस सुरक्षा नियमों में फ़ंक्शंस का उपयोग उन्हें अधिक रखरखाव योग्य बनाता है।
अगले कदम
शर्तों की इस चर्चा के बाद, आपको नियमों की अधिक परिष्कृत समझ मिल गई है और आप इसके लिए तैयार हैं:
जानें कि मुख्य उपयोग के मामलों को कैसे संभालना है, और नियमों के विकास, परीक्षण और तैनाती के लिए वर्कफ़्लो सीखें:
- ऐसे नियम लिखें जो सामान्य परिदृश्यों को संबोधित करें।
- उन स्थितियों की समीक्षा करके अपने ज्ञान का निर्माण करें जहां आपको असुरक्षित नियमों का पता लगाना चाहिए और उनसे बचना चाहिए ।
- क्लाउड स्टोरेज एमुलेटर और समर्पित सुरक्षा नियम परीक्षण लाइब्रेरी का उपयोग करके नियमों का परीक्षण करें।
- नियमों को तैनात करने के लिए उपलब्ध तरीकों की समीक्षा करें।