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

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

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Cloud Storage data.

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

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

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

service firebase.storage {
    // ...
}

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

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

बुनियादी नियमों में match स्टेटमेंट शामिल होता है, जो Cloud Storage बकेट की पहचान करता है. साथ ही, इसमें मैच स्टेटमेंट होता है, जो फ़ाइल नाम बताता है. इसके अलावा, इसमें 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.

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

किसी एक फ़ाइल को पॉइंट करने के अलावा, Security 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 (Security 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 उन्हें हल करने वाली परिभाषाएं देखें.

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