Firebase Cloud Storage के सुरक्षा नियमों में शर्तों का इस्तेमाल करना

इस गाइड में, Firebase Security Rules भाषा के मुख्य सिंटैक्स के बारे में जानें गाइड में दी गई जानकारी का इस्तेमाल किया गया है. इसमें बताया गया है कि Cloud Storage के लिए, Firebase Security Rules में शर्तें कैसे जोड़ी जाती हैं.

Cloud Storage Security Rules का मुख्य बिल्डिंग ब्लॉक, शर्त होती है. शर्त एक बूलियन एक्सप्रेशन है. इससे यह तय होता है कि किसी खास ऑपरेशन को अनुमति दी जानी चाहिए या नहीं. बुनियादी नियमों के लिए, शर्तों के तौर पर true और false लिटरल का इस्तेमाल करना सबसे सही तरीका है. हालांकि, Firebase Security Rules भाषा के लिए Cloud Storage की मदद से, ज़्यादा मुश्किल शर्तें लिखी जा सकती हैं. इनसे ये काम किए जा सकते हैं:

• उपयोगकर्ता की पुष्टि की जांच करना
• आने वाले डेटा की पुष्टि करना

पुष्टि करना

Firebase Security Rules, Firebase Authentication के साथ इंटिग्रेट होता है, ताकि Cloud Storage को उपयोगकर्ता के हिसाब से पुष्टि करने की बेहतर सुविधा मिल सके.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 न हो
• User private: check that request.auth.uid equals a path 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;
}

User private

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

इवैलुएशन का अनुरोध करना

अपलोड, डाउनलोड, मेटाडेटा में बदलाव, और मिटाने के अनुरोधों का आकलन करने के लिए, request को भेजे गए Cloud Storage का इस्तेमाल किया जाता है. ऊपर बताए गए तरीके के मुताबिक, request.auth ऑब्जेक्ट में मौजूद Firebase Authentication पेलोड और उपयोगकर्ता के यूनीक आईडी के अलावा, request वैरिएबल में वह फ़ाइल पाथ होता है जहां अनुरोध किया जा रहा है. साथ ही, इसमें अनुरोध मिलने का समय और नई resource वैल्यू होती है. हालांकि, ऐसा तब होता है, जब अनुरोध लिखने का हो.

request ऑब्जेक्ट में उपयोगकर्ता का यूनीक आईडी और request.auth ऑब्जेक्ट में Firebase Authentication पेलोड भी होता है. इसके बारे में दस्तावेज़ के उपयोगकर्ता के आधार पर सुरक्षा सेक्शन में ज़्यादा जानकारी दी गई है.

request ऑब्जेक्ट में मौजूद प्रॉपर्टी की पूरी सूची यहां दी गई है:

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

ध्यान दें: इन प्रॉपर्टी के बारे में ज़्यादा जानकारी, Firebase Security Rules for Cloud Storage API रेफ़रंस में उपलब्ध है.

संसाधन का आकलन

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

Cloud Storage के लिए Firebase Security Rules, resource ऑब्जेक्ट में फ़ाइल मेटाडेटा उपलब्ध कराता है. इसमें Cloud Storage ऑब्जेक्ट में मौजूद मेटाडेटा के की/वैल्यू पेयर होते हैं. डेटा की अखंडता को बनाए रखने के लिए, इन प्रॉपर्टी की जांच read या write अनुरोधों पर की जा सकती है.

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

resource ऑब्जेक्ट में मौजूद प्रॉपर्टी की पूरी सूची यहां दी गई है:

प्रॉपर्टी	टाइप	ब्यौरा
name	स्ट्रिंग	ऑब्जेक्ट का पूरा नाम
bucket	स्ट्रिंग	उस बकेट का नाम जिसमें यह ऑब्जेक्ट मौजूद है.
generation	int	इस ऑब्जेक्ट का Google Cloud Storage ऑब्जेक्ट जनरेशन.
metageneration	int	इस ऑब्जेक्ट का Google Cloud Storage object metageneration.
size	int	ऑब्जेक्ट का साइज़, बाइट में.
timeCreated	timestamp	यह टाइमस्टैंप, किसी ऑब्जेक्ट के बनाए जाने का समय दिखाता है.
updated	timestamp	यह टाइमस्टैंप, किसी ऑब्जेक्ट को पिछली बार अपडेट किए जाने का समय दिखाता है.
md5Hash	स्ट्रिंग	ऑब्जेक्ट का MD5 हैश.
crc32c	स्ट्रिंग	ऑब्जेक्ट का crc32c हैश.
etag	स्ट्रिंग	इस ऑब्जेक्ट से जुड़ा ईटैग.
contentDisposition	स्ट्रिंग	इस ऑब्जेक्ट से जुड़ा कॉन्टेंट डिसपोज़िशन.
contentEncoding	स्ट्रिंग	इस ऑब्जेक्ट से जुड़ी कॉन्टेंट एन्कोडिंग.
contentLanguage	स्ट्रिंग	इस ऑब्जेक्ट से जुड़ी कॉन्टेंट की भाषा.
contentType	स्ट्रिंग	इस ऑब्जेक्ट से जुड़ा कॉन्टेंट टाइप.
metadata	map<string, string>	डेवलपर के तय किए गए कस्टम मेटाडेटा के अतिरिक्त की/वैल्यू पेयर.

request.resource में generation, metageneration, etag, timeCreated, और updated को छोड़कर, ये सभी शामिल हैं.

ध्यान दें: इन प्रॉपर्टी के बारे में ज़्यादा जानकारी, Firebase Security Rules for Cloud Storage API रेफ़रंस में उपलब्ध है.

Cloud Firestore की मदद से बेहतर बनाएं

अन्य अनुमति की शर्तों का आकलन करने के लिए, Cloud Firestore में मौजूद दस्तावेज़ों को ऐक्सेस किया जा सकता है.

firestore.get() और firestore.exists() फ़ंक्शन का इस्तेमाल करके, सुरक्षा से जुड़े नियम यह आकलन कर सकते हैं कि Cloud Firestore में मौजूद दस्तावेज़ों के हिसाब से, आने वाले अनुरोध सही हैं या नहीं. firestore.get() और firestore.exists(), दोनों फ़ंक्शन के लिए दस्तावेज़ के पूरे पाथ की ज़रूरत होती है. firestore.get() और firestore.exists() के लिए पाथ बनाते समय वैरिएबल का इस्तेमाल करने पर, आपको $(variable) सिंटैक्स का इस्तेमाल करके वैरिएबल को साफ़ तौर पर एस्केप करना होगा.

ध्यान दें: Cloud Firestore दस्तावेज़ों को ऐक्सेस करने के किसी भी तरीके की तरह, Storage Rules से दस्तावेज़ों को पढ़ने की सुविधा का इस्तेमाल करने पर, आपके प्रोजेक्ट के Firestore कोटे और बिलिंग पर असर पड़ता है.

चेतावनी: एक से ज़्यादा डेटाबेस चालू होने पर, Storage Rules सिर्फ़ डिफ़ॉल्ट Cloud Firestore डेटाबेस के दस्तावेज़ों को ऐक्सेस कर सकता है.

यहां दिए गए उदाहरण में, हम एक ऐसा नियम देख रहे हैं जो फ़ाइलों को पढ़ने का ऐक्सेस सिर्फ़ उन लोगों को देता है जो किसी खास क्लब के सदस्य हैं.

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)).data.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 लेख में बताए गए तरीके से, आईएएम की भूमिका हटाकर इस सुविधा को बंद किया जा सकता है.

डेटा की पुष्टि करना

Firebase Security Rules का इस्तेमाल, डेटा की पुष्टि करने के लिए भी किया जा सकता है. इसमें ये शामिल हैं: फ़ाइल के नाम और पाथ की पुष्टि करना. साथ ही, फ़ाइल के मेटाडेटा की प्रॉपर्टी की पुष्टि करना. जैसे, contentType और size.Cloud Storage

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 कीवर्ड का इस्तेमाल करके वैरिएबल तय कर सकते हैं. फ़ंक्शन में कई let बाइंडिंग हो सकती हैं, लेकिन यह ज़रूरी है कि फ़ंक्शन, return स्टेटमेंट के साथ खत्म हो.

फ़ंक्शन को 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 के लिए उपलब्ध तरीके देखें.