सुरक्षा के बुनियादी नियम

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

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

अपने नियमों को ऐक्सेस करने और उन्हें अपडेट करने के लिए, यहां दिया गया तरीका अपनाएं Firebase Security Rules को मैनेज और डिप्लॉय करें.

डिफ़ॉल्ट नियम: लॉक किया गया मोड

Firebase कंसोल में डेटाबेस या स्टोरेज इंस्टेंस बनाने पर, आपको यह चुनना होगा कि Firebase Security Rules आपका डेटा ऐक्सेस करने पर पाबंदी लगाए या नहीं (लॉक मोड) या किसी को भी ऐक्सेस करने की अनुमति दें (टेस्ट मोड). Cloud Firestore और Realtime Database, लॉक मोड के डिफ़ॉल्ट नियम के मुताबिक, किसी भी उपयोगकर्ता को फ़ाइल का ऐक्सेस नहीं दिया जा सकता. Cloud Storage में, सिर्फ़ पुष्टि किए गए उपयोगकर्ता स्टोरेज बकेट को ऐक्सेस कर सकते हैं.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

डेवलपमेंट-एनवायरमेंट के नियम

अपने ऐप्लिकेशन पर काम करने के दौरान, हो सकता है कि आप ऐप्लिकेशन को पूरी तरह से खोलकर इस्तेमाल करना चाहें आपके डेटा का ऐक्सेस. बस अपने Rules को पहले अपडेट करें ऐप्लिकेशन को प्रोडक्शन में डिप्लॉय किया जाए. यह भी याद रखें कि अगर आपका ऐप्लिकेशन डिप्लॉय किया जाता है, तो तो इसे सार्वजनिक तौर पर ऐक्सेस किया जा सकता है. भले ही, आपने इसे लॉन्च न किया हो.

याद रखें कि Firebase क्लाइंट को आपके डेटा का सीधा ऐक्सेस देता है और नुकसान पहुंचाने वाले उपयोगकर्ताओं के लिए, सुरक्षा के उपाय के तौर पर Firebase Security Rules का ऐक्सेस ब्लॉक किया जा सकता है. प्रॉडक्ट लॉजिक से अलग नियम तय करने के कई फ़ायदे हैं: क्लाइंट को सुरक्षा लागू करने की ज़िम्मेदारी नहीं होती, गड़बड़ी वाले लागू होने से आपके डेटा को खतरा नहीं होगा, और सबसे ज़रूरी बात यह है कि आपको डेटा को दुनिया से सुरक्षित रखने के लिए, किसी इंटरमीडियरी सर्वर पर निर्भर नहीं रहना पड़ेगा.

सभी पुष्टि किए गए उपयोगकर्ता

हालांकि, हम यह सुझाव नहीं देते हैं कि आप अपना डेटा ऐसे किसी भी उपयोगकर्ता के लिए ऐक्सेस कर दें जो साइन इन किया है, तो किसी भी प्रमाणित उपयोगकर्ता की पहुंच सेट करना उपयोगी हो सकता है, जबकि तो आपका ऐप्लिकेशन कैसे डेवलप किया जा रहा है.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

प्रोडक्शन के लिए तैयार नियम

अपने ऐप्लिकेशन को डिप्लॉय करते समय, पक्का करें कि आपका डेटा सुरक्षित रहे और आपके उपयोगकर्ताओं को उचित रूप से ऐक्सेस दिया गया हो. फ़ायदा उपयोगकर्ता के हिसाब से ऐक्सेस सेट अप करने और सीधे पढ़ने के लिए Authentication अपने डेटाबेस से डेटा-आधारित ऐक्सेस सेट अप करने के लिए किया जा सकता है.

अपने डेटा को व्यवस्थित करते समय नियम लिखने पर विचार करें, क्योंकि नियमों को सेट करने पर, अलग-अलग पाथ.

सिर्फ़ कॉन्टेंट के मालिक के लिए ऐक्सेस

इन नियमों की वजह से, कॉन्टेंट का ऐक्सेस सिर्फ़ उस मालिक के पास होता है जिसकी पुष्टि हो चुकी है. कॉन्टेंट बनाने डेटा को सिर्फ़ एक उपयोगकर्ता ही पढ़ और लिख सकता है. साथ ही, डेटा पाथ में उपयोगकर्ता का आईडी सबमिट करें.

यह नियम कब काम करता है: अगर उपयोगकर्ता डेटा को अलग-अलग स्टोर में ले जाता है, तो यह नियम अच्छे से काम करता है — अगर जिस उपयोगकर्ता को डेटा ऐक्सेस करने की ज़रूरत होती है वही उपयोगकर्ता डेटा शामिल है.

यह नियम कब काम नहीं करता: यह नियम तब काम नहीं करता, जब एक से ज़्यादा उपयोगकर्ताओं को एक ही डेटा को लिखना या पढ़ना हो. ऐसे में, उपयोगकर्ता डेटा को ओवरराइट कर देंगे या अपने बनाए गए डेटा को ऐक्सेस नहीं कर पाएंगे.

यह नियम सेट अप करने के लिए: एक ऐसा नियम बनाएं जो ऐक्सेस का अनुरोध करने वाले उपयोगकर्ता की पुष्टि करता हो डेटा को पढ़ने या उसमें बदलाव करने की अनुमति वह उपयोगकर्ता है जिसके पास डेटा का मालिकाना हक होता है.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

सार्वजनिक और निजी, दोनों तरह का ऐक्सेस

इस नियम के तहत, कोई भी व्यक्ति डेटा सेट को पढ़ सकता है. हालांकि, किसी दिए गए पाथ पर डेटा बनाने या उसमें बदलाव करने की अनुमति सिर्फ़ पुष्टि किए गए कॉन्टेंट के मालिक को है.

यह नियम कब काम करता है: यह नियम उन ऐप्लिकेशन के लिए सही तरीके से काम करता है जिनके लिए सार्वजनिक तौर पर ऐप्लिकेशन उपलब्ध कराना ज़रूरी है ऐसे एलिमेंट जिन्हें पढ़ा जा सकता है, लेकिन उनमें बदलाव करने के ऐक्सेस पर पाबंदी लगानी होगी' मालिक. उदाहरण के लिए, चैट ऐप्लिकेशन या ब्लॉग.

यह नियम कब काम नहीं करता: सिर्फ़ कॉन्टेंट के मालिक के लिए बने नियम की तरह ही, यह नियम भी तब काम नहीं करता, जब एक ही डेटा में कई उपयोगकर्ताओं को बदलाव करना हो. उपयोगकर्ता यह कर पाएंगे एक-दूसरे के डेटा को ओवरराइट कर देते हैं.

यह नियम सेट अप करने के लिए: एक ऐसा नियम बनाएं जो सभी उपयोगकर्ताओं को पढ़ने का ऐक्सेस चालू करे या यह पुष्टि करता है कि डेटा लिखने वाले उपयोगकर्ता का मालिकाना हक है.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow create: if request.auth.uid == request.resource.data.author_uid;
      allow update, delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

एट्रिब्यूट और भूमिका के हिसाब से ऐक्सेस

इन नियमों को काम करने के लिए, आपको अपने डेटा शामिल है. Firebase Security Rules अपने डेटाबेस या फ़ाइल के डेटा के लिए अनुरोध की जांच करें ऐक्सेस की पुष्टि करने या न करने के लिए मेटाडेटा.

यह नियम कब काम करता है: अगर आप उपयोगकर्ताओं को कोई भूमिका असाइन कर रहे हैं, तो यह नियम भूमिकाओं या उपयोगकर्ताओं के खास ग्रुप के हिसाब से, ऐक्सेस को सीमित किया जा सकता है. उदाहरण के लिए, अगर आप ग्रेड स्टोर कर रहे थे, तो आप "छात्र-छात्राएं" ग्रुप (सिर्फ़ उनका कॉन्टेंट पढ़ने के लिए), "शिक्षक" ग्रुप (उनके विषय में पढ़ें और लिखें) और "प्रिंसिपल" ग्रुप (पूरा कॉन्टेंट पढ़ें).

यह नियम कब काम नहीं करता: Realtime Database और Cloud Storage में, आपके नियम get() के उस तरीके का फ़ायदा नहीं ले सकते जिसे Cloud Firestore नियम शामिल कर सकते हैं. इसलिए, आपको अपने डेटाबेस या फ़ाइल के मेटाडेटा को इस तरह तैयार करना होगा कि उन एट्रिब्यूट का इस्तेमाल करें जिनका इस्तेमाल आप अपने नियमों में कर रहे हैं.

यह नियम सेट अप करने के लिए: Cloud Firestore में अपने उपयोगकर्ताओं की जानकारी में एक फ़ील्ड शामिल करें दस्तावेज़ों को पढ़ सकते हैं, फिर उसे पढ़ने के लिए अपने नियम की संरचना तैयार करते हैं. फ़ील्ड में जोड़ें और शर्तों के साथ ऐक्सेस दें. Realtime Database में, एक ऐसा डेटा पाथ बनाएं जो आपके ऐप्लिकेशन के उपयोगकर्ताओं की जानकारी देता हो और उन्हें चाइल्ड नोड में भूमिका देता हो.

Authentication में कस्टम दावे भी सेट अप किए जा सकते हैं. इसके बाद, किसी भी Firebase Security Rules में auth.token वैरिएबल से वह जानकारी वापस पाई जा सकती है.

डेटा के हिसाब से तय किए गए एट्रिब्यूट और भूमिकाएं

ये नियम सिर्फ़ Cloud Firestore और Realtime Database में काम करते हैं.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

कस्टम-दावे वाले एट्रिब्यूट और भूमिकाएं

इन नियमों को लागू करने के लिए, पसंद के मुताबिक दावे सेट अप करें Firebase Authentication में सेट करें और फिर अपने नियमों में दिए गए दावों का फ़ायदा उठाएं.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // 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 Cloud Identity Platform (GCIP) में मल्टी-टेंनेंसी सेट अप करें. इसके बाद, अपने नियमों में टेंंट का फ़ायदा लें. यहां दिए गए उदाहरणों में, लिखने की अनुमति दी गई है किसी किराये पर रहने वाले उपयोगकर्ता से, जैसे कि tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}