फायरबेस उपयोगकर्ता वस्तु उस उपयोगकर्ता खाते का प्रतिनिधित्व करती है जिसने आपके प्रोजेक्ट में एक ऐप के लिए साइन अप किया है। ऐप्स में आमतौर पर कई पंजीकृत उपयोगकर्ता होते हैं, और प्रोजेक्ट में प्रत्येक ऐप एक उपयोगकर्ता डेटाबेस साझा करता है।
उपयोगकर्ता उदाहरण फायरबेस प्रमाणीकरण उदाहरणों से स्वतंत्र हैं, इसलिए आपके पास एक ही संदर्भ में विभिन्न उपयोगकर्ताओं के लिए कई संदर्भ हो सकते हैं और फिर भी उनके किसी भी तरीके को कॉल कर सकते हैं।
उपयोगकर्ता गुण
फायरबेस उपयोगकर्ताओं के पास मूल गुणों का एक निश्चित सेट होता है—एक अद्वितीय आईडी, एक प्राथमिक ईमेल पता, एक नाम और एक फोटो यूआरएल—प्रोजेक्ट के उपयोगकर्ता डेटाबेस में संग्रहीत, जिसे उपयोगकर्ता ( आईओएस , एंड्रॉइड , वेब ) द्वारा अपडेट किया जा सकता है। आप अन्य गुणों को सीधे उपयोगकर्ता ऑब्जेक्ट में नहीं जोड़ सकते; इसके बजाय, आप अतिरिक्त संपत्तियों को Google क्लाउड फायरस्टोर जैसी किसी भी अन्य स्टोरेज सेवाओं में स्टोर कर सकते हैं।
जब कोई उपयोगकर्ता पहली बार आपके ऐप में साइन अप करता है, तो उपलब्ध जानकारी का उपयोग करके उपयोगकर्ता का प्रोफ़ाइल डेटा भर दिया जाता है:
- यदि उपयोगकर्ता ने एक ईमेल पते और पासवर्ड के साथ साइन अप किया है, तो केवल प्राथमिक ईमेल पता गुण पॉप्युलेट किया जाता है
- यदि उपयोगकर्ता ने फ़ेडरेटेड पहचान प्रदाता, जैसे कि Google या Facebook के साथ साइन अप किया है, तो प्रदाता द्वारा उपलब्ध कराई गई खाता जानकारी का उपयोग उपयोगकर्ता की प्रोफ़ाइल को पॉप्युलेट करने के लिए किया जाता है
- यदि उपयोगकर्ता ने आपके कस्टम प्रमाणीकरण सिस्टम के साथ साइन अप किया है, तो आपको स्पष्ट रूप से वह जानकारी जोड़नी होगी जो आप उपयोगकर्ता की प्रोफ़ाइल में चाहते हैं
एक बार एक उपयोगकर्ता खाता बन जाने के बाद, उपयोगकर्ता द्वारा किसी अन्य डिवाइस पर किए गए किसी भी परिवर्तन को शामिल करने के लिए आप उपयोगकर्ता की जानकारी को पुनः लोड कर सकते हैं।
साइन-इन प्रदाता
आप कई विधियों का उपयोग करके उपयोगकर्ताओं को अपने ऐप में साइन इन कर सकते हैं: ईमेल पता और पासवर्ड, फ़ेडरेटेड पहचान प्रदाता, और आपका कस्टम प्रमाणीकरण सिस्टम। आप एक उपयोगकर्ता के साथ एक से अधिक साइन-इन पद्धति को संबद्ध कर सकते हैं: उदाहरण के लिए, एक उपयोगकर्ता ईमेल पते और पासवर्ड का उपयोग करके या Google साइन-इन का उपयोग करके उसी खाते में साइन इन कर सकता है।
उपयोगकर्ता उदाहरण उपयोगकर्ता से जुड़े प्रत्येक प्रदाता का ट्रैक रखते हैं। यह आपको प्रदाता द्वारा दी गई जानकारी का उपयोग करके खाली प्रोफ़ाइल की संपत्तियों को अपडेट करने की अनुमति देता है। उपयोगकर्ताओं को प्रबंधित करना देखें ( आईओएस , एंड्रॉइड , वेब )।
वर्तमान उपयोगकर्ता
जब कोई उपयोगकर्ता साइन अप या साइन इन करता है, तो वह उपयोगकर्ता प्रामाणिक उदाहरण का वर्तमान उपयोगकर्ता बन जाता है। इंस्टेंस उपयोगकर्ता की स्थिति को बनाए रखता है, ताकि पृष्ठ को रीफ़्रेश (ब्राउज़र में) या एप्लिकेशन को पुनरारंभ करने से उपयोगकर्ता की जानकारी नष्ट न हो.
जब उपयोगकर्ता साइन आउट करता है, तो प्रामाणिक उदाहरण उपयोगकर्ता ऑब्जेक्ट का संदर्भ रखना बंद कर देता है और अब उसकी स्थिति बनी नहीं रहती है; कोई वर्तमान उपयोगकर्ता नहीं है। हालांकि, उपयोगकर्ता का उदाहरण पूरी तरह कार्यात्मक बना रहता है: यदि आप इसका संदर्भ रखते हैं, तो भी आप उपयोगकर्ता के डेटा तक पहुंच और अद्यतन कर सकते हैं।
उपयोगकर्ता जीवनचक्र
ऑथ उदाहरण की वर्तमान स्थिति को ट्रैक करने का अनुशंसित तरीका श्रोताओं (जावास्क्रिप्ट में "पर्यवेक्षक" भी कहा जाता है) का उपयोग कर रहा है। जब भी प्रामाणिक वस्तु से संबंधित कुछ होता है तो प्रामाणिक श्रोता को अधिसूचित किया जाता है। उपयोगकर्ताओं को प्रबंधित करना देखें ( आईओएस , एंड्रॉइड , वेब )।
एक प्रामाणिक श्रोता को निम्न स्थितियों में अधिसूचित किया जाता है:
- ऑथ ऑब्जेक्ट प्रारंभ करना समाप्त करता है और उपयोगकर्ता पहले से ही पिछले सत्र से साइन इन था, या पहचान प्रदाता के साइन-इन प्रवाह से रीडायरेक्ट किया गया है
- एक उपयोगकर्ता साइन इन करता है (वर्तमान उपयोगकर्ता सेट है)
- एक उपयोगकर्ता साइन आउट करता है (वर्तमान उपयोगकर्ता शून्य हो जाता है)
- वर्तमान उपयोगकर्ता का एक्सेस टोकन रीफ्रेश किया गया है। यह मामला निम्न स्थितियों में हो सकता है:
- एक्सेस टोकन समाप्त हो रहा है: यह एक सामान्य स्थिति है। टोकन का नया वैध सेट प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग किया जाता है।
- उपयोगकर्ता अपना पासवर्ड बदलता है: फायरबेस नई पहुंच और रीफ्रेश टोकन जारी करता है और पुराने टोकन की समय सीमा समाप्त कर देता है। यह सुरक्षा कारणों से उपयोगकर्ता के टोकन को स्वचालित रूप से समाप्त कर देता है और/या प्रत्येक डिवाइस पर उपयोगकर्ता को साइन आउट कर देता है।
- उपयोगकर्ता पुनः प्रमाणित करता है: कुछ कार्रवाइयों के लिए आवश्यक है कि उपयोगकर्ता के क्रेडेंशियल हाल ही में जारी किए गए हों; ऐसी कार्रवाइयों में खाता हटाना, प्राथमिक ईमेल पता सेट करना और पासवर्ड बदलना शामिल है। उपयोगकर्ता को साइन आउट करने और फिर उपयोगकर्ता में फिर से साइन इन करने के बजाय, उपयोगकर्ता से नए क्रेडेंशियल्स प्राप्त करें, और नए क्रेडेंशियल्स को उपयोगकर्ता ऑब्जेक्ट की पुन: प्रमाणीकरण विधि में पास करें।
उपयोगकर्ता स्वयं सेवा
डिफ़ॉल्ट रूप से, फायरबेस उपयोगकर्ताओं को प्रशासनिक हस्तक्षेप के बिना अपने खातों को साइन-अप करने और हटाने में सक्षम बनाता है। कई परिस्थितियों में, यह एंड-यूजर्स को न्यूनतम घर्षण के साथ आपके एप्लिकेशन या सेवा और ऑनबोर्ड (या ऑफबोर्ड) की खोज करने में सक्षम बनाता है।
हालाँकि, ऐसी परिस्थितियाँ होती हैं, जहाँ आप चाहते हैं कि उपयोगकर्ता व्यवस्थापक SDK या Firebase कंसोल का उपयोग करके व्यवस्थापक द्वारा मैन्युअल रूप से या प्रोग्रामेटिक रूप से बनाए जाएँ। इन मामलों में, आप फायरबेस ऑथेंटिकेशन सेटिंग्स पेज से उपयोगकर्ता क्रियाओं को अक्षम कर सकते हैं, जो एंड-यूजर्स द्वारा खाता निर्माण और विलोपन को रोकता है। यदि आप बहु-किरायेदारी का उपयोग कर रहे हैं, तो आपको प्रति-किरायेदार आधार पर इन सुविधाओं को अक्षम करने के लिए एक HTTP अनुरोध करना होगा।
यदि कोई अंतिम-उपयोगकर्ता आपके सिस्टम के भीतर खाता बनाने या हटाने का प्रयास करता है, तो फायरबेस सेवा एक त्रुटि कोड वापस करेगी: वेब एपीआई कॉल के लिए ऑथ auth/admin-restricted-operation , या एंड्रॉइड और आईओएस के लिए ERROR_ADMIN_RESTRICTED_OPERATION । उपयोगकर्ता को आपकी सेवा के लिए उचित कार्रवाई करने के लिए कहकर आपको अपने फ्रंट-एंड पर त्रुटि को शालीनता से संभालना चाहिए।
प्रामाणिक टोकन
जब आप फायरबेस के साथ प्रमाणीकरण करते हैं, तो आपको तीन प्रकार के प्रमाणीकरण टोकन मिल सकते हैं:
| फायरबेस आईडी टोकन | Firebase द्वारा बनाया गया जब कोई उपयोगकर्ता किसी ऐप में साइन इन करता है। ये टोकन हस्ताक्षरित JWTs हैं जो फायरबेस प्रोजेक्ट में एक उपयोगकर्ता की सुरक्षित पहचान करते हैं। इन टोकन में उपयोगकर्ता की आईडी स्ट्रिंग सहित उपयोगकर्ता के लिए मूल प्रोफ़ाइल जानकारी होती है, जो कि फायरबेस प्रोजेक्ट के लिए अद्वितीय है। क्योंकि आईडी टोकन की अखंडता को सत्यापित किया जा सकता है , आप वर्तमान में साइन-इन किए गए उपयोगकर्ता की पहचान करने के लिए उन्हें बैकएंड सर्वर पर भेज सकते हैं। |
| पहचान प्रदाता टोकन | फ़ेडरेटेड पहचान प्रदाताओं, जैसे Google और Facebook द्वारा बनाया गया। इन टोकन के अलग-अलग प्रारूप हो सकते हैं, लेकिन अक्सर OAuth 2.0 एक्सेस टोकन होते हैं। ऐप्स इन टोकन का उपयोग यह सत्यापित करने के लिए करते हैं कि उपयोगकर्ताओं ने पहचान प्रदाता के साथ सफलतापूर्वक प्रमाणित किया है, और फिर उन्हें फायरबेस सेवाओं द्वारा उपयोग करने योग्य क्रेडेंशियल्स में परिवर्तित करें। |
| फायरबेस कस्टम टोकन | उपयोगकर्ताओं को आपके प्रमाणीकरण सिस्टम का उपयोग करके ऐप में साइन इन करने की अनुमति देने के लिए आपके कस्टम प्रमाणीकरण सिस्टम द्वारा बनाया गया। कस्टम टोकन JWTs होते हैं जिन पर सेवा खाते की निजी कुंजी का उपयोग करके हस्ताक्षर किए जाते हैं। ऐप्स इन टोकन का उपयोग उसी तरह करते हैं जैसे वे फ़ेडरेटेड पहचान प्रदाताओं से लौटाए गए टोकन का उपयोग करते हैं। |
सत्यापित ईमेल पते
फायरबेस एक ईमेल को सत्यापित मानता है यदि यह दो शर्तों को पूरा करता है:
- उपयोगकर्ता Firebase सत्यापन प्रक्रिया को पूरा करता है
- ईमेल एक विश्वसनीय पहचान प्रदाता, या संक्षेप में IdP द्वारा सत्यापित किया जाता है।
IdPs जो ईमेल को एक बार सत्यापित करते हैं, लेकिन फिर उपयोगकर्ताओं को पुन: सत्यापन की आवश्यकता के बिना ईमेल पते बदलने की अनुमति देते हैं, उन पर भरोसा नहीं किया जाता है। वे IdPs जो या तो डोमेन के स्वामी हैं या जिन्हें हमेशा सत्यापन की आवश्यकता होती है, विश्वसनीय माने जाते हैं।
विश्वसनीय प्रदाता:
- Google (@gmail.com पतों के लिए)
- Yahoo (@yahoo.com पतों के लिए)
- Microsoft (@outlook.com और @hotmail.com पतों के लिए)
- Apple (हमेशा सत्यापित, क्योंकि खाते हमेशा सत्यापित और बहु-कारक-प्रमाणित होते हैं)
अविश्वसनीय प्रदाता:
- फेसबुक
- ट्विटर
- GitHub
- Google, Yahoo, और Microsoft उन डोमेन के लिए जो उस पहचान प्रदाता द्वारा जारी नहीं किए गए हैं
- ईमेल / पासवर्ड ईमेल सत्यापन के बिना
कुछ स्थितियों में, जब कोई उपयोगकर्ता एक ही ईमेल पते का उपयोग करके विभिन्न प्रदाताओं के साथ साइन इन करता है, तो Firebase स्वचालित रूप से खातों को लिंक कर देगा। यह तभी हो सकता है जब विशिष्ट मानदंड पूरे हों। क्यों समझने के लिए, निम्नलिखित स्थिति पर विचार करें: एक उपयोगकर्ता @gmail.com खाते के साथ Google का उपयोग करके साइन इन करता है और एक दुर्भावनापूर्ण अभिनेता उसी @gmail.com पते का उपयोग करके एक खाता बनाता है, लेकिन फेसबुक के माध्यम से साइन इन करता है। यदि ये दो खाते स्वचालित रूप से लिंक हो जाते हैं, तो दुर्भावनापूर्ण अभिनेता उपयोगकर्ता के खाते तक पहुंच प्राप्त कर लेगा।
निम्नलिखित मामले वर्णन करते हैं कि कब हम स्वचालित रूप से खातों को लिंक करते हैं और जब हम उपयोगकर्ता या डेवलपर कार्रवाई की आवश्यकता वाली त्रुटि फेंकते हैं:
- उपयोगकर्ता किसी अविश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल से किसी अन्य अविश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, Facebook जिसके बाद GitHub आता है)। यह खाता लिंकिंग की आवश्यकता वाली त्रुटि फेंकता है।
- उपयोगकर्ता एक विश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल के साथ अविश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, फेसबुक के बाद Google)। यह खाता लिंकिंग की आवश्यकता वाली त्रुटि फेंकता है।
- उपयोगकर्ता एक अविश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल के साथ एक विश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, Google द्वारा अनुसरण किया जाने वाला Facebook)। विश्वसनीय प्रदाता अविश्वसनीय प्रदाता को अधिलेखित कर देता है। यदि उपयोगकर्ता फेसबुक के साथ फिर से साइन इन करने का प्रयास करता है, तो यह खाता लिंकिंग की आवश्यकता में त्रुटि उत्पन्न करेगा।
- उपयोगकर्ता किसी विश्वसनीय प्रदाता के साथ साइन इन करता है, फिर उसी ईमेल से किसी भिन्न विश्वसनीय प्रदाता के साथ साइन इन करता है (उदाहरण के लिए, Apple जिसके बाद Google आता है)। दोनों प्रदाताओं को बिना किसी त्रुटि के लिंक किया जाएगा।
आप व्यवस्थापक SDK का उपयोग करके किसी ईमेल को मैन्युअल रूप से सत्यापित के रूप में सेट कर सकते हैं, लेकिन हम ऐसा केवल तभी करने की अनुशंसा करते हैं यदि आप जानते हैं कि उपयोगकर्ता वास्तव में ईमेल का स्वामी है.