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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

इस गाइड में, Cloud Storage के लिए Firebase Security Rules में शर्तें जोड़ने का तरीका बताया गया है. यह तरीका, 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 ऑब्जेक्ट में मौजूद प्रॉपर्टी की पूरी सूची यहां दी गई है:

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

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

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

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

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

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 कीवर्ड का इस्तेमाल करके वैरिएबल तय कर सकते हैं. फ़ंक्शन में जितनी चाहे उतनी 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 को डिप्लॉय करने के लिए उपलब्ध तरीकों की समीक्षा करें.