Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

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

प्रमाणीकरण

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

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

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

जब कोई unauthenticated उपयोगकर्ता अनुरोध करता है, तो 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 वैरिएबल सभी unauthenticated उपयोगकर्ताओं के लिए null , आपको बस इतना करना है कि request.auth वैरिएबल की जाँच करें ताकि प्रमाणीकरण की आवश्यकता हो:

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

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

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

चूंकि Google क्लाउड स्टोरेज में फाइलों के लिए एक पूर्ण "पथ" है, इसलिए उपयोगकर्ता द्वारा नियंत्रित की गई फ़ाइल को बनाने के लिए सभी को एक अद्वितीय चीज़ मिलती है, उपयोगकर्ता फ़ाइल नाम उपसर्ग (जैसे उपयोगकर्ता का 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;
}

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

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

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

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

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

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

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

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

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

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

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

request.resource के अपवाद के साथ इन सभी का होता है generation , metageneration , etag , timeCreated , और updated

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

क्लाउड संग्रहण के लिए 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/.*');
    }
  }
}

कस्टम कार्य

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

  • फ़ंक्शंस में केवल एक ही return स्टेटमेंट हो सकता है। उनमें कोई अतिरिक्त तर्क नहीं हो सकता। उदाहरण के लिए, वे छोरों को निष्पादित नहीं कर सकते हैं या बाहरी सेवाओं को कॉल नहीं कर सकते हैं।
  • फ़ंक्शंस फ़ंक्शंस और वेरिएबल्स को उस दायरे से स्वचालित रूप से एक्सेस कर सकते हैं जिसमें वे परिभाषित हैं। उदाहरण के लिए, service firebase.storage स्कोप के भीतर परिभाषित एक फंक्शन के पास resource वैरिएबल तक पहुंच है, और क्लाउड फायरस्टार के लिए, बिल्ट-इन फंक्शन जैसे कि exists() और exists() 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();
    }
  }
}

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

अगला कदम

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

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