यह गाइड Firebase Security Rules भाषा के मुख्य सिंटैक्स के बारे में जानें गाइड पर आधारित है Cloud Storage के लिए, अपने Firebase Security Rules में शर्तें जोड़ने का तरीका दिखाएं.
Cloud Storage Security Rules का मुख्य बिल्डिंग ब्लॉक शर्त है. ऐप्लिकेशन
शर्त एक बूलियन एक्सप्रेशन है, जिससे यह तय होता है कि कोई खास कार्रवाई
अनुमति दी जानी चाहिए या नहीं. सामान्य नियमों के लिए, true
और false
की लिटरल वैल्यू का इस्तेमाल करना
बिलकुल वैसे ही काम करता है. वहीं, Cloud Storage के लिए Firebase Security Rules
भाषा की सहायता से आप ज़्यादा जटिल स्थितियां लिख सकते हैं, जो:
- उपयोगकर्ता की पुष्टि की जांच करना
- आने वाले डेटा की पुष्टि करना
पुष्टि करना
Cloud Storage के लिए Firebase Security Rules, Firebase Authentication के साथ इंटिग्रेट हो जाता है, ताकि Cloud Storage के लिए शक्तिशाली उपयोगकर्ता आधारित प्रमाणीकरण. इससे आपको Firebase Authentication टोकन के दावों के आधार पर विस्तृत ऐक्सेस कंट्रोल.
जब पुष्टि किए गए उपयोगकर्ता, Cloud Storage के ख़िलाफ़ अनुरोध करते हैं, तो request.auth
वैरिएबल में उपयोगकर्ता के uid
(request.auth.uid
) के साथ-साथ Firebase Authentication 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
का सबसे सामान्य इस्तेमाल का उदाहरण
ऐसे उपयोगकर्ता जिनके पास अपनी फ़ाइलों पर पूरी अनुमतियां हैं: प्रोफ़ाइल फ़ोटो अपलोड करने से
निजी दस्तावेज़ों को पढ़ने के लिए डिज़ाइन किया गया है.
Cloud Storage में मौजूद फ़ाइलों का पूरा "पाथ" होता है. इसलिए, किसी फ़ाइल को उपयोगकर्ता के कंट्रोल में रखने के लिए, फ़ाइल के नाम के प्रीफ़िक्स में उपयोगकर्ता की पहचान करने वाली यूनीक जानकारी (जैसे, उपयोगकर्ता का 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; }
समूह निजी
इस्तेमाल का एक और आम उदाहरण यह है कि किसी ऑब्जेक्ट पर ग्रुप की अनुमतियां दी जाएं. जैसे, टीम के कई सदस्यों को शेयर किए गए दस्तावेज़ पर मिलकर काम करने की अनुमति देना. यह लीजिए ऐसा करने के कई तरीके हैं:
- Firebase Authentication कस्टम टोकन मिंट करें जिसमें ग्रुप के किसी सदस्य के बारे में ज़्यादा जानकारी शामिल हो. जैसे, ग्रुप आईडी
- इसमें ग्रुप की जानकारी (जैसे कि ग्रुप आईडी या अनुमति वाले
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; }
आकलन का अनुरोध करना
अपलोड, डाउनलोड, मेटाडेटा में बदलाव, और मिटाए गए कॉन्टेंट का आकलन करने के लिए,
Cloud Storage को request
भेजे गए. इसके अलावा, उपयोगकर्ता के यूनीक आईडी और
ऊपर बताए गए तरीके के मुताबिक, request.auth
ऑब्जेक्ट में Firebase Authentication पेलोड,
request
वैरिएबल में वह फ़ाइल पाथ शामिल है जहां अनुरोध किया जा रहा है
की गई कार्रवाई, अनुरोध मिलने का समय, और resource
की नई वैल्यू
अगर उसे कॉपी किया गया है.
request
ऑब्जेक्ट में उपयोगकर्ता का यूनीक आईडी और
request.auth
ऑब्जेक्ट में Firebase Authentication पेलोड, जो
उपयोगकर्ता पर आधारित सुरक्षा सेक्शन में, इस बारे में ज़्यादा जानकारी दी गई है
सेक्शन में जाएं.
request
ऑब्जेक्ट में प्रॉपर्टी की पूरी सूची नीचे दी गई है:
प्रॉपर्टी | टाइप | ब्यौरा |
---|---|---|
auth |
मैप<स्ट्रिंग, स्ट्रिंग> | जब कोई उपयोगकर्ता लॉग इन होता है, तो uid , उपयोगकर्ता का यूनीक आईडी और
token , Firebase Authentication जेडब्लयूटी दावों का मैप उपलब्ध कराता है. ऐसा न करने पर, यह
null होगा. |
params |
मैप<स्ट्रिंग, स्ट्रिंग> | अनुरोध के क्वेरी पैरामीटर वाला मैप. |
path |
पाथ | अनुरोध किए जा रहे पाथ को दिखाने वाला path
ने कैसा परफ़ॉर्म किया. |
resource |
मैप<स्ट्रिंग, स्ट्रिंग> | नई संसाधन वैल्यू, सिर्फ़ write अनुरोध पर मौजूद है.
|
time |
timestamp | अनुरोध का आकलन करने के लिए सर्वर के समय को दिखाने वाला टाइमस्टैंप. |
संसाधनों का आकलन
नियमों का मूल्यांकन करते समय, हो सकता है कि आप फ़ाइल के मेटाडेटा का मूल्यांकन भी करना चाहें अपलोड, डाउनलोड, संशोधित या हटाया जा रहा है. इसकी मदद से, जटिल और बेहतर नियम बनाए जा सकते हैं. जैसे, सिर्फ़ कुछ तरह के कॉन्टेंट वाली फ़ाइलों को अपलोड करने की अनुमति देना या सिर्फ़ तय साइज़ से बड़ी फ़ाइलों को मिटाना.
Cloud Storage के लिए Firebase Security Rules, resource
ऑब्जेक्ट में फ़ाइल का मेटाडेटा उपलब्ध कराता है. इसमें Cloud Storage ऑब्जेक्ट में दिखाए गए मेटाडेटा के की/वैल्यू पेयर शामिल होते हैं. इन प्रॉपर्टी की जांच read
पर की जा सकती है या
डेटा के रखरखाव को पक्का करने के लिए write
अनुरोध.
write
के अनुरोधों (जैसे कि अपलोड करना, मेटाडेटा अपडेट करना, और मिटाना) पर
resource
ऑब्जेक्ट के अलावा, जिसमें फ़ाइल का फ़ाइल मेटाडेटा भी होता है
जो वर्तमान में अनुरोध पथ पर मौजूद है, तो आपके पास
request.resource
ऑब्जेक्ट, जिसमें इस फ़ाइल मेटाडेटा का सबसेट शामिल होता है
लिखा जाएगा. यह पक्का करने के लिए कि डेटा
इंटिग्रिटी की अनुमति दें या ऐप्लिकेशन की पाबंदियां लागू करें. जैसे, फ़ाइल टाइप या साइज़.
resource
ऑब्जेक्ट में मौजूद प्रॉपर्टी की पूरी सूची यहां दी गई है:
प्रॉपर्टी | टाइप | ब्यौरा |
---|---|---|
name |
स्ट्रिंग | ऑब्जेक्ट का पूरा नाम |
bucket |
स्ट्रिंग | उस बकेट का नाम जिसमें यह ऑब्जेक्ट है. |
generation |
int | Google Cloud Storage इस ऑब्जेक्ट का ऑब्जेक्ट जनरेट करने की सुविधा. |
metageneration |
int | Google Cloud Storage इस ऑब्जेक्ट का ऑब्जेक्ट मेटाजनरेशन है. |
size |
int | ऑब्जेक्ट का साइज़, बाइट में. |
timeCreated |
timestamp | ऑब्जेक्ट बनाए जाने के समय को दिखाने वाला टाइमस्टैंप. |
updated |
timestamp | ऑब्जेक्ट को आखिरी बार अपडेट किए जाने का समय दिखाने वाला टाइमस्टैंप. |
md5Hash |
स्ट्रिंग | ऑब्जेक्ट का MD5 हैश. |
crc32c |
स्ट्रिंग | ऑब्जेक्ट का crc32c हैश. |
etag |
स्ट्रिंग | इस ऑब्जेक्ट से जुड़ा etag. |
contentDisposition |
स्ट्रिंग | इस ऑब्जेक्ट से जुड़ा कॉन्टेंट मैनेजमेंट. |
contentEncoding |
स्ट्रिंग | इस ऑब्जेक्ट के साथ जुड़ी कॉन्टेंट एन्कोडिंग. |
contentLanguage |
स्ट्रिंग | इस ऑब्जेक्ट के कॉन्टेंट की भाषा. |
contentType |
स्ट्रिंग | इस ऑब्जेक्ट से जुड़ा कॉन्टेंट टाइप. |
metadata |
map<string, string> | डेवलपर की ओर से बताए गए कस्टम मेटाडेटा के कुंजी/वैल्यू पेयर. |
request.resource
में generation
को छोड़कर, ये सभी शामिल हैं,
metageneration
, etag
, timeCreated
, और updated
.
Cloud Firestore की मदद से बेहतर बनाएं
अनुमति के अन्य अनुरोधों की समीक्षा करने के लिए, Cloud Firestore में दस्तावेज़ों को ऐक्सेस किया जा सकता है शर्तें.
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)) } } }
इन Cloud Firestore का इस्तेमाल करने वाले पहले Cloud Storage Security Rules को बनाने और सेव करने के बाद आपसे Firebase कंसोल या Firebase सीएलआई में दोनों प्रॉडक्ट को कनेक्ट करने के लिए अनुमतियां चालू करें.
इस सुविधा को बंद करने के लिए, आईएएम की भूमिका को हटाएं. इसके बारे में यहां बताया गया है Firebase Security Rules को मैनेज और डिप्लॉय करें.
डेटा की पुष्टि करें
डेटा की पुष्टि करने के लिए, Cloud Storage के लिए Firebase Security Rules का इस्तेमाल भी किया जा सकता है. इसमें ये चीज़ें शामिल हैं
फ़ाइल नाम और पाथ के साथ-साथ फ़ाइल मेटाडेटा प्रॉपर्टी की पुष्टि करना
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 Security Rules ज़्यादा जटिल होता जाएगा, हो सकता है कि आप शर्तों में शामिल है, जिन्हें आप अपने नियमसेट में फिर से इस्तेमाल कर सकते हैं. सुरक्षा के नियम सुविधा, जिसमें कस्टम फ़ंक्शन इस्तेमाल किए जा सकते हैं. कस्टम फ़ंक्शन का सिंटैक्स कुछ-कुछ JavaScript जैसा है. लेकिन Firebase Security Rules फ़ंक्शन किसी डोमेन की खास भाषा में लिखे गए हैं जिसमें कुछ अहम सीमाएं हैं:
- फ़ंक्शन में सिर्फ़ एक
return
स्टेटमेंट हो सकता है. इनमें कोई और लॉजिक नहीं हो सकता. उदाहरण के लिए, वे लूप नहीं चला सकते या बाहरी सेवाओं को कॉल करें. - फ़ंक्शन, उन फ़ंक्शन और वैरिएबल को अपने-आप ऐक्सेस कर सकते हैं जिनके लिए उन्हें तय किया गया है. उदाहरण के लिए,
service firebase.storage
स्कोप के पासresource
वैरिएबल. साथ ही, सिर्फ़ Cloud Firestore के लिए, पहले से मौजूद फ़ंक्शन जैसे कि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 Security Rules में फ़ंक्शन का इस्तेमाल करने से, इन्हें जटिलता के तौर पर ज़्यादा मैनेज किया जा सकता है समय बढ़ता है.
अगले चरण
शर्तों पर चर्चा करने के बाद, अब आपकी रणनीति नियमों को समझ लेती है और इनके लिए तैयार है:
इस्तेमाल के मुख्य उदाहरणों को मैनेज करने का तरीका जानें. साथ ही, अपने कारोबार को डेवलप करने, टेस्ट करने और डिप्लॉय करने के नियम:
- सामान्य स्थितियों के बारे में बताने वाले नियम लिखें.
- उन स्थितियों की समीक्षा करके अपना ज्ञान बढ़ाएं जहां आपको असुरक्षित नियमों को पहचानने और उनसे बचने की ज़रूरत होती है.
- Cloud Storage एम्युलेटर और खास तौर पर बनाए गए सुरक्षा नियमों वाली टेस्ट लाइब्रेरी का इस्तेमाल करके, नियमों की जांच करें.
- Rules को डिप्लॉय करने के लिए उपलब्ध तरीके देखें.