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

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

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

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

  • uid : अनुरोध करने वाले उपयोगकर्ता को निर्दिष्ट एक अद्वितीय उपयोगकर्ता आईडी।
  • token : प्रमाणीकरण द्वारा एकत्रित मूल्यों का नक्शा।

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

खेत विवरण
email खाते से संबद्ध ईमेल पता, यदि मौजूद हो।
email_verified true अगर उपयोगकर्ता ने सत्यापित किया है कि उनके पास email पते तक पहुंच है। कुछ प्रदाता स्वचालित रूप से उनके स्वामित्व वाले ईमेल पतों को सत्यापित करते हैं।
phone_number खाते से संबद्ध फ़ोन नंबर, यदि मौजूद हो।
name उपयोगकर्ता का प्रदर्शन नाम, यदि सेट किया गया हो।
sub उपयोगकर्ता का Firebase UID. यह एक परियोजना के भीतर अद्वितीय है।
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

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

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

auth चर के बारे में अधिक जानकारी के लिए, Cloud Firestore , Realtime Database और Cloud Storage के लिए संदर्भ दस्तावेज़ देखें।

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

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

अपने नियमों में, परिभाषित करें कि 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 चर का उपयोग करके उन कस्टम दावों को संदर्भित कर सकते हैं।

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

{
  "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;
  }
}

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