Cloud Storage की भाषा के लिए Firebase के सुरक्षा नियमों से जुड़े मुख्य सिंटैक्स को जानें

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

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

इस गाइड में, पूरे नियमों का सेट बनाने के लिए, Cloud Storage Security Rules के बुनियादी सिंटैक्स और स्ट्रक्चर के बारे में बताया गया है.

सेवा और डेटाबेस से जुड़ा एलान

Cloud Storage के लिए Firebase Security Rules हमेशा इस एलान से शुरू होता है:

service firebase.storage {
    // ...
}

service firebase.storage एलान, Cloud Storage के लिए नियमों का दायरा तय करता है. इससे Cloud Storage Security Rules और Cloud Firestore जैसे दूसरे प्रॉडक्ट के नियमों के बीच होने वाले संघर्ष को रोका जा सकता है.

पढ़ने/लिखने के बुनियादी नियम

बुनियादी नियमों में, Cloud Storage बकेट की पहचान करने वाला match स्टेटमेंट, फ़ाइल का नाम बताने वाला मैच स्टेटमेंट, और तय किए गए डेटा को पढ़ने की अनुमति कब है, इस बारे में बताने वाला allow एक्सप्रेशन शामिल होता है. allow एक्सप्रेशन से, ऐक्सेस करने के तरीकों (जैसे, पढ़ना, लिखना) और उन शर्तों के बारे में पता चलता है जिनके तहत ऐक्सेस की अनुमति दी जाती है या नहीं दी जाती.

आपके डिफ़ॉल्ट नियमों के सेट में, पहला match स्टेटमेंट {bucket} वाइल्डकार्ड के इस्तेमाल करता है, ताकि यह पता चल सके कि नियम आपके प्रोजेक्ट की सभी बकेट पर लागू होते हैं. हम अगले सेक्शन में, वाइल्डकार्ड मैच के बारे में ज़्यादा बात करेंगे.

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

सभी मैच स्टेटमेंट, फ़ाइलों पर ले जाते हैं. मैच स्टेटमेंट किसी खास फ़ाइल पर ले जा सकता है, जैसा कि match /images/profilePhoto.png में है.

मैच करने वाले वाइल्डकार्ड

किसी एक फ़ाइल को पॉइंट करने के अलावा, Rules वाइल्डकार्ड का इस्तेमाल करके, नाम में किसी दी गई स्ट्रिंग प्रीफ़िक्स वाली किसी भी फ़ाइल को पॉइंट कर सकता है. इसमें स्लैश भी शामिल हैं, जैसे कि match /images/{imageId} में.

ऊपर दिए गए उदाहरण में, मैच स्टेटमेंट में {imageId} वाइल्डकार्ड सिंटैक्स का इस्तेमाल किया गया है. इसका मतलब है कि यह नियम, नाम की शुरुआत में /images/ वाली किसी भी फ़ाइल पर लागू होता है. जैसे, /images/profilePhoto.png या /images/croppedProfilePhoto.png. जब मैच स्टेटमेंट में allow एक्सप्रेशन का आकलन किया जाता है, तो imageId वैरिएबल, इमेज फ़ाइल के नाम पर सेट हो जाएगा, जैसे कि profilePhoto.png या croppedProfilePhoto.png.

फ़ाइल का नाम या पाथ की अनुमति देने के लिए, match में मौजूद वाइल्डकार्ड वैरिएबल का रेफ़रंस दिया जा सकता है:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

हैरारकी वाला डेटा

जैसा कि हमने पहले बताया था, Cloud Storage बकेट में कोई हैरारकी नहीं होती. हालांकि, फ़ाइल के नाम रखने के लिए आम तौर पर इस्तेमाल किए जाने वाले तरीके का इस्तेमाल करके, हम ऐसा स्ट्रक्चर बना सकते हैं जो डायरेक्ट्री और सब-डायरेक्ट्री की नेस्ट की गई सीरीज़ जैसा दिखता है. आम तौर पर, इस तरीके में फ़ाइल के नाम में स्लैश शामिल होते हैं. यह समझना ज़रूरी है कि Firebase Security Rules इन फ़ाइल नामों के साथ कैसे इंटरैक्ट करता है.

/images/ स्टैम से शुरू होने वाले नामों वाली फ़ाइलों के सेट की स्थिति पर विचार करें. Firebase Security Rules सिर्फ़ मैच होने वाले फ़ाइल नाम पर लागू होता है. इसलिए, /images/ स्टेम पर तय किए गए ऐक्सेस कंट्रोल, /mp3s/ स्टेम पर लागू नहीं होते. इसके बजाय, फ़ाइल नाम के अलग-अलग पैटर्न से मैच करने वाले साफ़ तौर पर लिखे गए नियम बनाएं:

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

match स्टेटमेंट को नेस्ट करते समय, अंदरूनी match स्टेटमेंट का पाथ, हमेशा बाहरी match स्टेटमेंट के पाथ में जोड़ दिया जाता है. इसलिए, ये दो नियमों के सेट एक जैसे हैं:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

बार-बार मैच करने वाले वाइल्डकार्ड

फ़ाइल के नाम के आखिर में मौजूद स्ट्रिंग से मैच करने और उन्हें दिखाने वाले वाइल्डकार्ड के अलावा, ज़्यादा जटिल मैचिंग के लिए एक से ज़्यादा सेगमेंट वाला वाइल्डकार्ड इस्तेमाल किया जा सकता है. इसके लिए, वाइल्डकार्ड के नाम में =** जोड़ें, जैसे कि {path=**}:

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

अगर एक से ज़्यादा नियम किसी फ़ाइल से मैच करते हैं, तो नतीजा सभी नियमों के आकलन के नतीजे का OR होता है. इसका मतलब है कि अगर फ़ाइल किसी नियम से मैच करती है और उसका नतीजा true है, तो नतीजा true होगा.

ऊपर दिए गए नियमों में, "images/profilePhoto.png" फ़ाइल को तब पढ़ा जा सकता है, जब condition या other_condition का आकलन सही हो. वहीं, "images/users/user:12345/profilePhoto.png" फ़ाइल को सिर्फ़ other_condition के नतीजे के हिसाब से पढ़ा जा सकता है.

Cloud Storage Security Rules कैस्केड नहीं होते. साथ ही, नियमों का आकलन सिर्फ़ तब किया जाता है, जब अनुरोध पाथ, बताए गए नियमों वाले पाथ से मेल खाता हो.

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

ज़्यादा जानकारी वाली कार्रवाइयां

कुछ मामलों में, read और write को ज़्यादा बारीक ऑपरेशन में बांटना फ़ायदेमंद होता है. उदाहरण के लिए, हो सकता है कि आपका ऐप्लिकेशन फ़ाइल बनाने के लिए, फ़ाइल मिटाने के लिए तय की गई शर्तों से अलग शर्तें लागू करना चाहे.

read ऑपरेशन को get और list में बांटा जा सकता है.

write नियम को create, update, और delete में बांटा जा सकता है:

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

ओवरलैप होने वाले मैच स्टेटमेंट

किसी फ़ाइल का नाम, एक से ज़्यादा match स्टेटमेंट से मैच हो सकता है. अगर एक से ज़्यादा allow एक्सप्रेशन किसी अनुरोध से मेल खाते हैं, तो ऐक्सेस तब दिया जाता है, जब कोई भी शर्त true हो:

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

ऊपर दिए गए उदाहरण में, /images/ से शुरू होने वाली फ़ाइलों को पढ़ने और उनमें बदलाव करने की अनुमति है. इसकी वजह यह है कि दूसरा नियम हमेशा true होता है, भले ही पहला नियम false हो.

नियम, फ़िल्टर नहीं होते

अपना डेटा सुरक्षित करने और फ़ाइल से जुड़े काम शुरू करने के बाद, ध्यान रखें कि सुरक्षा नियम, फ़िल्टर नहीं होते. फ़ाइल के नाम के पैटर्न से मैच करने वाली फ़ाइलों के सेट पर कोई कार्रवाई नहीं की जा सकती. साथ ही, यह उम्मीद नहीं की जा सकती कि Cloud Storage सिर्फ़ उन फ़ाइलों को ऐक्सेस करेगा जिनका ऐक्सेस मौजूदा क्लाइंट के पास है.

उदाहरण के लिए, सुरक्षा से जुड़ा यह नियम देखें:

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

अस्वीकार किया गया: यह नियम, नीचे दिए गए अनुरोध को अस्वीकार करता है, क्योंकि नतीजे के सेट में ऐसी फ़ाइलें शामिल हो सकती हैं जिनमें contentType, image/png नहीं है:

filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Cloud Storage Security Rules में मौजूद नियम, हर क्वेरी का आकलन उसके संभावित नतीजे के आधार पर करते हैं. अगर क्वेरी से ऐसी फ़ाइल मिलती है जिसे क्लाइंट पढ़ने की अनुमति नहीं है, तो अनुरोध अस्वीकार कर दिया जाता है. ऐक्सेस के अनुरोध, आपके नियमों के मुताबिक होने चाहिए.

अगले चरण

Cloud Storage के लिए Firebase Security Rules को बेहतर तरीके से समझने के लिए:

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

• सुरक्षा से जुड़े सामान्य इस्तेमाल के उदाहरणों और उनसे जुड़ी Firebase Security Rules परिभाषाओं की समीक्षा करें.

Firebase Security Rules के इस्तेमाल के उदाहरणों को Cloud Storage के हिसाब से एक्सप्लोर किया जा सकता है: