सुरक्षा नियम और फायरबेस प्रमाणीकरण

फायरबेस सुरक्षा नियम एक ऐसे प्रारूप में पहुंच नियंत्रण और डेटा सत्यापन प्रदान करते हैं जो जटिलता के कई स्तरों का समर्थन करता है। अपने उपयोगकर्ताओं के डेटा को सुरक्षित रखने वाले उपयोगकर्ता-आधारित और भूमिका-आधारित एक्सेस सिस्टम बनाने के लिए, फ़ायरबेस सुरक्षा नियमों के साथ फ़ायरबेस प्रमाणीकरण का उपयोग करें।

उपयोगकर्ताओं को पहचानें

प्रमाणीकरण आपके डेटा तक पहुंच का अनुरोध करने वाले उपयोगकर्ताओं की पहचान करता है और उस जानकारी को एक चर के रूप में प्रदान करता है जिसका लाभ आप अपने नियमों में उठा सकते हैं। auth वैरिएबल में निम्नलिखित जानकारी शामिल है:

  • uid : एक अद्वितीय उपयोगकर्ता आईडी, जो अनुरोध करने वाले उपयोगकर्ता को सौंपी गई है।
  • token : प्रमाणीकरण द्वारा एकत्रित मूल्यों का एक मानचित्र।

auth.token वैरिएबल में निम्नलिखित मान हैं:

मैदान विवरण
email खाते से संबद्ध ईमेल पता, यदि मौजूद है।
email_verified true यदि उपयोगकर्ता ने सत्यापित कर लिया है कि उनके पास email पते तक पहुंच है। कुछ प्रदाता अपने स्वामित्व वाले ईमेल पते को स्वचालित रूप से सत्यापित करते हैं।
phone_number खाते से संबद्ध फ़ोन नंबर, यदि मौजूद है।
name उपयोगकर्ता का प्रदर्शन नाम, यदि सेट हो।
sub उपयोगकर्ता का फायरबेस यूआईडी. यह किसी प्रोजेक्ट के भीतर अद्वितीय है.
firebase.identities इस उपयोगकर्ता के खाते से संबद्ध सभी पहचानों का शब्दकोश। शब्दकोश की कुंजियाँ निम्नलिखित में से कोई भी हो सकती हैं: email , phone , google.com , facebook.com , github.com , twitter.com । शब्दकोश के मान खाते से जुड़े प्रत्येक पहचान प्रदाता के लिए विशिष्ट पहचानकर्ताओं की सारणी हैं। उदाहरण के लिए, auth.token.firebase.identities["google.com"][0] में खाते से संबद्ध पहली Google उपयोगकर्ता आईडी शामिल है।
firebase.sign_in_provider साइन-इन प्रदाता इस टोकन को प्राप्त करता था। निम्नलिखित स्ट्रिंग में से एक हो सकता है: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com
firebase.tenant खाते से संबद्ध किरायेदार आईडी, यदि मौजूद है। उदाहरण के लिए tenant2-m6tyz

यदि आप अनुकूलित प्रमाणीकरण विशेषताएँ जोड़ना चाहते हैं, तो auth.token वैरिएबल में आपके द्वारा निर्दिष्ट कोई भी कस्टम दावा भी शामिल है।

जब एक्सेस का अनुरोध करने वाला उपयोगकर्ता साइन इन नहीं होता है, तो auth वैरिएबल null है। आप अपने नियमों में इसका लाभ उठा सकते हैं, उदाहरण के लिए, यदि आप प्रमाणित उपयोगकर्ताओं तक पढ़ने की पहुंच को सीमित करना चाहते हैं - auth != null । हालाँकि, हम आम तौर पर आगे लिखने की पहुंच को सीमित करने की सलाह देते हैं।

auth वेरिएबल के बारे में अधिक जानकारी के लिए, क्लाउड फायरस्टोर , रीयलटाइम डेटाबेस और क्लाउड स्टोरेज के लिए संदर्भ दस्तावेज़ देखें।

नियमों में उपयोगकर्ता जानकारी का लाभ उठाएं

व्यवहार में, अपने नियमों में प्रमाणित जानकारी का उपयोग करने से आपके नियम अधिक शक्तिशाली और लचीले हो जाते हैं। आप उपयोगकर्ता की पहचान के आधार पर डेटा तक पहुंच को नियंत्रित कर सकते हैं।

अपने नियमों में, परिभाषित करें कि auth वैरिएबल में जानकारी - अनुरोधकर्ता की उपयोगकर्ता जानकारी - अनुरोधित डेटा से जुड़ी उपयोगकर्ता जानकारी से कैसे मेल खाती है।

उदाहरण के लिए, आपका ऐप शायद यह सुनिश्चित करना चाहेगा कि उपयोगकर्ता केवल अपना डेटा पढ़ और लिख सकें। इस परिदृश्य में, आप अनुरोधित डेटा पर auth.uid वैरिएबल और उपयोगकर्ता आईडी के बीच एक मिलान चाहेंगे:

क्लाउड फायरस्टोर

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

रीयलटाइम डेटाबेस

{
  "rules": {
    "users": {
      "$userId": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($userId)
        ".write": "$userId === auth.uid"
      }
    }
  }
}

घन संग्रहण

service firebase.storage {
  // Only a user can upload their file, but anyone can view it
  match /users/{userId}/{fileName} {
    allow read;
    allow write: if request.auth != null && request.auth.uid == userId;
  }
}

कस्टम उपयोगकर्ता जानकारी को परिभाषित करें

आप अपने ऐप के उपयोगकर्ताओं को निर्दिष्ट कस्टम फ़ील्ड को परिभाषित करने के लिए auth वेरिएबल का और अधिक लाभ उठा सकते हैं।

उदाहरण के लिए, मान लें कि आप एक "व्यवस्थापक" भूमिका बनाना चाहते हैं जो कुछ पथों पर लिखने की पहुंच सक्षम करती है। आप उस विशेषता को उपयोगकर्ताओं को निर्दिष्ट करेंगे, और फिर पथों पर पहुंच प्रदान करने वाले नियमों में इसका लाभ उठाएंगे।

क्लाउड फायरस्टोर में, आप उपयोगकर्ताओं के दस्तावेज़ों में एक कस्टम फ़ील्ड जोड़ सकते हैं और अपने नियमों में एम्बेडेड रीड के साथ उस फ़ील्ड का मान पुनः प्राप्त कर सकते हैं। तो, आपका व्यवस्थापक-आधारित नियम निम्नलिखित उदाहरण जैसा दिखेगा:

क्लाउड फायरस्टोर

service cloud.firestore {
  match /databases/{database}/documents/some_collection: {
    // Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
    write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
    read: if request.auth != null;
  }
}

प्रमाणीकरण में कस्टम दावे बनाने के बाद आप नियमों में कस्टम दावों तक पहुंच सकते हैं। फिर आप auth.token वैरिएबल का उपयोग करके उन कस्टम दावों का संदर्भ दे सकते हैं।

क्लाउड फायरस्टोर

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/$sub_path": {
      // Create a custom claim for the admin role
      ".write": "auth.uid !== null && auth.token.writer === true"
      ".read": "auth.uid !== null"
      }
    }
  }

घन संग्रहण

service firebase.storage {
  // Create a custom claim for the admin role
  match /files/{fileName} {
    allow read: if request.auth.uid != null;
    allow write: if request.auth.token.admin == true;
  }
}

प्रमाणीकरण का लाभ उठाने वाले बुनियादी नियमों के अधिक उदाहरण देखने के लिए, बुनियादी सुरक्षा नियम देखें।