Firebase प्रोजेक्ट में उपयोगकर्ता

फायरबेस उपयोगकर्ता ऑब्जेक्ट एक उपयोगकर्ता खाते का प्रतिनिधित्व करता है जिसने आपके प्रोजेक्ट में एक ऐप के लिए साइन अप किया है। ऐप्स में आमतौर पर कई पंजीकृत उपयोगकर्ता होते हैं, और प्रोजेक्ट में प्रत्येक ऐप एक उपयोगकर्ता डेटाबेस साझा करता है।

उपयोगकर्ता इंस्टेंसेस फायरबेस प्रमाणीकरण इंस्टेंसेस से स्वतंत्र हैं, इसलिए आपके पास एक ही संदर्भ में विभिन्न उपयोगकर्ताओं के लिए कई संदर्भ हो सकते हैं और फिर भी उनके किसी भी तरीके को कॉल कर सकते हैं।

उपयोगकर्ता गुण

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

जब कोई उपयोगकर्ता पहली बार आपके ऐप पर साइन अप करता है, तो उपलब्ध जानकारी का उपयोग करके उपयोगकर्ता का प्रोफ़ाइल डेटा पॉप्युलेट किया जाता है:

• यदि उपयोगकर्ता ने ईमेल पते और पासवर्ड के साथ साइन अप किया है, तो केवल प्राथमिक ईमेल पता प्रॉपर्टी पॉप्युलेट होती है
• यदि उपयोगकर्ता ने Google या Facebook जैसे फ़ेडरेटेड पहचान प्रदाता के साथ साइन अप किया है, तो प्रदाता द्वारा उपलब्ध कराई गई खाता जानकारी का उपयोग उपयोगकर्ता की प्रोफ़ाइल को पॉप्युलेट करने के लिए किया जाता है।
• यदि उपयोगकर्ता ने आपके कस्टम ऑथ सिस्टम के साथ साइन अप किया है, तो आपको उपयोगकर्ता की प्रोफ़ाइल में वह जानकारी स्पष्ट रूप से जोड़नी होगी जो आप चाहते हैं

एक बार उपयोगकर्ता खाता बन जाने के बाद, आप उपयोगकर्ता की जानकारी को किसी अन्य डिवाइस पर उपयोगकर्ता द्वारा किए गए किसी भी बदलाव को शामिल करने के लिए पुनः लोड कर सकते हैं।

साइन-इन प्रदाता

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

उपयोगकर्ता इंस्टेंसेस उपयोगकर्ता से जुड़े प्रत्येक प्रदाता पर नज़र रखता है। यह आपको प्रदाता द्वारा दी गई जानकारी का उपयोग करके खाली प्रोफ़ाइल के गुणों को अपडेट करने की अनुमति देता है। उपयोगकर्ताओं को प्रबंधित करना ( आईओएस , एंड्रॉइड , वेब ) देखें।

वर्तमान उपयोगकर्ता

जब कोई उपयोगकर्ता साइन अप या साइन इन करता है, तो वह उपयोगकर्ता प्रामाणिक उदाहरण का वर्तमान उपयोगकर्ता बन जाता है। उदाहरण उपयोगकर्ता की स्थिति को बनाए रखता है, ताकि पृष्ठ को ताज़ा करने (ब्राउज़र में) या एप्लिकेशन को पुनरारंभ करने से उपयोगकर्ता की जानकारी न खोए।

जब उपयोगकर्ता साइन आउट करता है, तो प्रामाणिक उदाहरण उपयोगकर्ता ऑब्जेक्ट का संदर्भ रखना बंद कर देता है और अपनी स्थिति को बनाए नहीं रखता है; कोई वर्तमान उपयोगकर्ता नहीं है. हालाँकि, उपयोगकर्ता इंस्टेंस पूरी तरह कार्यात्मक बना हुआ है: यदि आप इसका संदर्भ रखते हैं, तो भी आप उपयोगकर्ता के डेटा तक पहुंच और अपडेट कर सकते हैं।

उपयोगकर्ता जीवनचक्र

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

एक प्रामाणिक श्रोता को निम्नलिखित स्थितियों में सूचित किया जाता है:

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

उपयोगकर्ता स्व-सेवा

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

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

यदि कोई अंतिम-उपयोगकर्ता आपके सिस्टम के भीतर खाता बनाने या हटाने का प्रयास करता है, तो फायरबेस सेवा एक त्रुटि कोड लौटाएगी: वेब एपीआई कॉल के लिए auth/admin-restricted-operation , या एंड्रॉइड और आईओएस के लिए ERROR_ADMIN_RESTRICTED_OPERATION । आपको उपयोगकर्ता से आपकी सेवा के लिए उचित कार्रवाई करने के लिए कहकर अपने फ्रंट-एंड पर त्रुटि को शालीनता से संभालना चाहिए।

प्रामाणिक टोकन

जब आप फायरबेस के साथ प्रमाणीकरण करते हैं, तो आपको तीन प्रकार के ऑथ टोकन का सामना करना पड़ सकता है:

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

सत्यापित ईमेल पते

यदि कोई ईमेल दो शर्तों को पूरा करता है तो फायरबेस उसे सत्यापित मानता है:

1. उपयोगकर्ता फायरबेस सत्यापन प्रवाह पूरा करता है
2. ईमेल को किसी विश्वसनीय पहचान प्रदाता या संक्षेप में आईडीपी द्वारा सत्यापित किया जाता है।

आईडीपी जो ईमेल को एक बार सत्यापित करते हैं, लेकिन फिर उपयोगकर्ताओं को पुन: सत्यापन की आवश्यकता के बिना ईमेल पते बदलने की अनुमति देते हैं, उन पर भरोसा नहीं किया जाता है। जिन आईडीपी के पास या तो डोमेन होता है या जिन्हें हमेशा सत्यापन की आवश्यकता होती है, उन्हें विश्वसनीय माना जाता है।

विश्वसनीय प्रदाता:

• Google (@gmail.com पतों के लिए)
• याहू (@yahoo.com पतों के लिए)
• Microsoft (@outlook.com और @hotmail.com पतों के लिए)
• Apple (हमेशा सत्यापित, क्योंकि खाते हमेशा सत्यापित और बहु-कारक-प्रमाणित होते हैं)

अविश्वसनीय प्रदाता:

• फेसबुक
• ट्विटर
• GitHub
• Google, Yahoo, और Microsoft उन डोमेन के लिए जो उस पहचान प्रदाता द्वारा जारी नहीं किए गए हैं
• ईमेल सत्यापन के बिना ईमेल/पासवर्ड

कुछ स्थितियों में, जब कोई उपयोगकर्ता एक ही ईमेल पते का उपयोग करके विभिन्न प्रदाताओं के साथ साइन इन करता है तो फायरबेस स्वचालित रूप से खातों को लिंक कर देगा। हालाँकि, यह तभी हो सकता है जब विशिष्ट मानदंड पूरे हों। इसका कारण समझने के लिए, निम्नलिखित स्थिति पर विचार करें: एक उपयोगकर्ता @gmail.com खाते के साथ Google का उपयोग करके साइन इन करता है और एक दुर्भावनापूर्ण अभिनेता उसी @gmail.com पते का उपयोग करके एक खाता बनाता है, लेकिन फेसबुक के माध्यम से साइन इन करता है। यदि ये दोनों खाते स्वचालित रूप से लिंक हो जाते, तो दुर्भावनापूर्ण अभिनेता उपयोगकर्ता के खाते तक पहुंच प्राप्त कर लेता।

निम्नलिखित मामले बताते हैं कि कब हम खातों को स्वचालित रूप से लिंक करते हैं और कब हम उपयोगकर्ता या डेवलपर कार्रवाई की आवश्यकता वाली त्रुटि उत्पन्न करते हैं:

• उपयोगकर्ता एक अविश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल के साथ किसी अन्य अविश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, फेसबुक और उसके बाद GitHub)। इससे खाता लिंक करने की आवश्यकता वाली त्रुटि उत्पन्न होती है.
• उपयोगकर्ता किसी विश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल से अविश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, Google के बाद Facebook)। इससे खाता लिंक करने की आवश्यकता वाली त्रुटि उत्पन्न होती है.
• उपयोगकर्ता एक अविश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल के साथ एक विश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, फेसबुक के बाद Google)। विश्वसनीय प्रदाता अविश्वसनीय प्रदाता को अधिलेखित कर देता है। यदि उपयोगकर्ता फेसबुक के साथ दोबारा साइन इन करने का प्रयास करता है, तो इससे खाता लिंक करने की आवश्यकता में त्रुटि उत्पन्न होगी।
• उपयोगकर्ता एक विश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल के साथ एक अलग विश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, Apple के बाद Google)। दोनों प्रदाता बिना किसी त्रुटि के जुड़े रहेंगे।

आप एडमिन एसडीके का उपयोग करके किसी ईमेल को मैन्युअल रूप से सत्यापित के रूप में सेट कर सकते हैं, लेकिन हम ऐसा केवल तभी करने की सलाह देते हैं यदि आप जानते हैं कि उपयोगकर्ता वास्तव में ईमेल का स्वामी है।