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

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

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

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

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

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

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

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 चर को अपने ऐप्लिकेशन के उपयोगकर्ताओं को सौंपा कस्टम फ़ील्ड परिभाषित करने के लिए।

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

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

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

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

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