इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

उपयोगकर्ता आधारित सुरक्षा

यह दस्तावेज़ आपके डेटा को सुरक्षित रखने से अवधारणाओं को फिर से परिभाषित करता है, जिसमें हमारे डेटा को सुरक्षित करने के लिए एक पूर्ण समाधान बनाने के लिए पूर्वनिर्धारित auth शामिल किया गया है।

प्रमाणीकरण को एकीकृत करना

फायरबेस ऑथेंटिकेशन, आपको प्रति उपयोगकर्ता के आधार पर डेटा एक्सेस को नियंत्रित करने की अनुमति देने के लिए फायरबेस रियलटाइम डेटाबेस के साथ एकीकृत करता है

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

यह मार्गदर्शिका बताती है कि अपने उपयोगकर्ताओं के बारे में प्रमाणीकरण जानकारी के साथ फायरबेस रियलटाइम डेटाबेस नियम भाषा को कैसे संयोजित करें। इन दो अवधारणाओं को मिलाकर, आप उपयोगकर्ता की पहचान के आधार पर डेटा तक पहुंच को नियंत्रित कर सकते हैं।

auth चर

प्रमाणीकरण होने से पहले नियमों में पूर्वनिर्धारित auth चर शून्य है। एक बार एक उपयोगकर्ता को फायरबेस प्रमाणीकरण के साथ प्रमाणित करने के बाद , इसमें निम्नलिखित विशेषताएं होंगी:

प्रदाता प्रमाणीकरण विधि ("पासवर्ड", "अनाम", "फेसबुक", "जीथब", "गूगल", या "ट्विटर") का उपयोग किया।
uid एक अद्वितीय उपयोगकर्ता आईडी, सभी प्रदाताओं में अद्वितीय होने की गारंटी।
टोकन Firebase Auth ID टोकन की सामग्री। अधिक जानकारी के लिए auth.token लिए संदर्भ प्रलेखन देखें।

यहाँ एक उदाहरण नियम का उपयोग करता है है auth चर यह सुनिश्चित करें कि प्रत्येक उपयोगकर्ता केवल एक उपयोगकर्ता-विशिष्ट पथ लिख सकते हैं:

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

अपने डेटाबेस को संरचित करना

यह कभी-कभी आपके डेटाबेस को इस तरह से संरचित करने में सहायक होता है जो सुरक्षा नियमों को लिखना आसान बनाता है। एक उदाहरण के रूप में, रीयलटाइम डेटाबेस में उपयोगकर्ता डेटा को संग्रहीत करने के लिए एक सामान्य पैटर्न आपके सभी उपयोगकर्ताओं को एकल users नोड में संग्रहीत करना है जिनके बच्चे प्रत्येक उपयोगकर्ता के लिए uid मान हैं। यदि आप इस डेटा तक पहुंच को प्रतिबंधित करना चाहते हैं, ताकि केवल लॉग-इन उपयोगकर्ता ही अपना डेटा देख सकें, तो आपके नियम कुछ इस तरह दिखाई देंगे:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid"
      }
    }
  }
}

प्रमाणीकरण कस्टम दावों के साथ काम करना

विभिन्न उपयोगकर्ताओं के लिए कस्टम एक्सेस कंट्रोल की आवश्यकता वाले ऐप्स के लिए, Firebase Authentication डेवलपर्स को Firebase उपयोगकर्ता पर दावे सेट करने की अनुमति देता है। ये दावे आपके नियमों में स्थित auth.token वेरिएबल में मौजूद हैं। यहाँ नियमों का एक उदाहरण दिया गया है जो hasEmergencyTowel का उपयोग करते हैं। कस्टम दावा:

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

अपने स्वयं के कस्टम प्रमाणीकरण टोकन बनाने वाले डेवलपर्स वैकल्पिक रूप से इन टोकन में दावे जोड़ सकते हैं। ये दावे आपके नियमों में auth.tokenauth.token चर पर उपलब्ध हैं।

चैट उदाहरण को फिर से देखना

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

{
  "rules": {
    "room_names": {
      // any logged in user can get a list of room names
      ".read": "auth !== null",

      "$room_id": {
        // this is just for documenting the structure of rooms, since
        // they are read-only and no write rule allows this to be set
        ".validate": "newData.isString()"
      }
    },

    "members": {
       // I can join or leave any room (otherwise it would be a boring demo)
       // I can have a different name in each room just for fun
       "$room_id": {
          // any member can read the list of member names
          ".read": "data.child(auth.uid).exists()",

          // room must already exist to add a member
          ".validate": "root.child('room_names/'+$room_id).exists()",

          "$user_id": {
             ".write": "auth.uid === $user_id",
             ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length < 20"
          }
       }
    },

    "messages": {
      "$room_id": {
        // the list of messages for a room can be read by any member
        ".read": "root.child('members/'+$room_id+'/'+auth.uid).exists()",

        // room we want to write a message to must be valid
        ".validate": "root.child('room_names/'+$room_id).exists()",

        "$message_id": {
          // a new message can be created if it does not exist, but it
          // cannot be modified or deleted
          // any member of a room can write a new message
          ".write": "root.child('members/'+$room_id+'/'+auth.uid).exists() && !data.exists() && newData.exists()",

          // the room attribute must be a valid key in room_names/ (the room must exist)
          // the object to write must have a name, message, and timestamp
          ".validate": "newData.hasChildren(['user', 'message', 'timestamp'])",

          // the message must be written by logged in user
          "user": {
             ".validate": "newData.val() === auth.uid"
          },

          // the message must be longer than 0 chars and less than 50
          "message": { ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length < 50" },

          // messages cannot be added in the past or the future
          // clients should use firebase.database.ServerValue.TIMESTAMP
          // to ensure accurate timestamps
          "timestamp": { ".validate": "newData.val() <= now" },

          // no other fields can be included in a message
          "$other": { ".validate": false }
        }
      }
    }
  }
}

अगला कदम