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