एक साथ कई उपयोगकर्ता खातों के विलय के लिए वास्तुकला


176

ठीक है, मुझे एक वेबसाइट मिली है जहाँ आप अपना पंजीकरण कर सकते हैं और लॉगिन कर सकते हैं। आप अपने फेसबुक, ट्विटर या लिंक्डइन अकाउंट से भी लॉगिन कर सकते हैं।

यह महत्वपूर्ण है कि उपयोगकर्ताओं के पास केवल एक खाता पंजीकृत है। इसलिए किसी तरह, मैं उपयोगकर्ताओं के खातों को मर्ज करना चाहता हूं यदि वे लॉगिन करने के लिए विभिन्न तरीकों का उपयोग करते हैं। इसे हल करने का सबसे अच्छा उपाय क्या है?

उदाहरण के लिए, उपयोगकर्ता अपने फेसबुक अकाउंट से लॉग इन करता है। मैं स्वतः ही उसके लिए खाता पंजीकृत करने के लिए डेटा का उपयोग करता हूं। क्या मुझे हमारी वेबसाइट के उपयोगकर्ता नाम और पासवर्ड के साथ एक ई-मेल भेजना चाहिए? (यदि यह फेसबुक की नीति से ठीक है)। क्या मुझे उन्हें दूसरी स्क्रीन देनी चाहिए जहां वे उपयोगकर्ता नाम और पासवर्ड भर सकते हैं? लेकिन यह आपके फेसबुक अकाउंट के साथ लॉग इन करने के पीछे का विचार नहीं है। इसमें भाग लेने के लिए अपनी प्रक्रिया को सरल बनाना चाहिए।

यह भी संभव है कि उपयोगकर्ता ने हमारी वेबसाइट पर खुद को पंजीकृत किया हो और अगली बार वह अपने ट्विटर अकाउंट से लॉग इन करे। मैं इन 2 खातों को एक के रूप में कैसे मर्ज कर सकता हूं? सबसे अच्छा तरीका क्या है?

तो मूल रूप से मेरा सवाल है: मुझे 4 अलग-अलग तरीके मिले जो एक उपयोगकर्ता हमारी वेबसाइट का सदस्य बनता है। यदि कोई उपयोगकर्ता एक से अधिक तरीकों का उपयोग करने का निर्णय लेता है तो मैं इन सभी 4 तरीकों से केवल एक खाता कैसे बना सकता हूं? यह सुनिश्चित करने के लिए सबसे अच्छा प्रवाह क्या है कि यह स्वयं उपयोगकर्ता के लिए परेशानी का कारण न बने?


संपादित करें:

यह प्रश्न पूछने के 3 साल बाद, मैं लेखों की एक श्रृंखला में खुद को जवाब दे रहा हूं: https://www.peternijssen.nl/social-network-authentication-setup/
https : //www.peternijssen.nl-social- नेटवर्क-प्रमाणीकरण-Google /
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/


7
बेशक, स्टैक ओवरफ्लो जैसी कई लॉगिन विधियों की अनुमति देकर किसी उपयोगकर्ता को पहली बार में कई खाते रखने से रोकने की कोशिश करना सबसे अच्छा है, लेकिन यहां तक ​​कि SO के पास मॉडरेटर्स के लिए खातों को मर्ज करने की क्षमता है। मैं किसी ऐसे व्यक्ति के लिए इनाम की पेशकश कर रहा हूं जो इसे अनुमति देने के लिए वास्तुकला का वर्णन कर सकता है। "अपडेट पोस्ट सेट यूजरआईडी = 2 जहां
यूजरआईडी

ईमेल और फोन मर्जिंग कुंजी के रूप में इस्तेमाल किया जा सकता है, किसी भी अन्य?
वूनर

नमस्कार, आपके द्वारा प्रदान किया गया लिंक काम नहीं करता है। यह करने के लिए साइट के मुखपृष्ठ केवल चला जाता है
vigamage

लिंक अपडेट किया गया। लेख हालांकि 6 साल पुराने हैं।
पीटी

जवाबों:


120

मैं इस समय एक ही कार्य के साथ सामना कर रहा हूँ। जिस डिजाइन पर मैंने काम किया है वह सरल है, लेकिन यह अच्छी तरह से काम करता है।

मुख्य विचार यह है कि एक स्थानीय साइट पहचान और तृतीय-पक्ष साइट पहचान के लिए मॉडल अलग-थलग रखे जाते हैं, लेकिन बाद में लिंक किए जाते हैं। इसलिए साइट में लॉग इन करने वाले प्रत्येक उपयोगकर्ता की एक स्थानीय पहचान होती है जो किसी भी तीसरे पक्ष की साइट पहचान के लिए मैप करता है।

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

तृतीय-पक्ष की पहचान में केवल तृतीय-पक्ष के साथ प्रमाणीकरण करने के लिए प्रासंगिक जानकारी होती है। OAuth के लिए, इसका आम तौर पर एक उपयोगकर्ता पहचानकर्ता (जैसे आईडी, ईमेल या उपयोगकर्ता नाम) और एक सेवा पहचानकर्ता होता है (यह दर्शाता है कि किस साइट या सेवा का प्रमाणीकरण किया गया था)। डेटाबेस के बाहर, अनुप्रयोग के अन्य हिस्सों में, उस सेवा पहचानकर्ता को उस सेवा से संबंधित उपयोगकर्ता पहचानकर्ता को पुनर्प्राप्त करने के लिए एक विधि के साथ जोड़ा जाता है, और इसी तरह प्रमाणीकरण किया जाता है। OpenID के लिए, हम एक ही दृष्टिकोण को नियोजित करते हैं, प्रमाणीकरण के लिए विधि को और अधिक सामान्यीकृत किया जाता है (क्योंकि हम लगभग हमेशा एक ही प्रोटोकॉल का प्रदर्शन कर सकते हैं - सिवाय इसके कि हम एक अलग पहचान URL का उपयोग करें, और वह हमारी सेवा पहचानकर्ता है)।

अंत में, मैं एक रिकॉर्ड रखता हूं कि किस तीसरे पक्ष की पहचान को स्थानीय पहचान से जोड़ा गया है। इन अभिलेखों को उत्पन्न करने के लिए, प्रवाह इस तरह दिखता है:

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

खातों को विलय करना स्थानीय पहचान के प्रत्येक व्यक्ति के क्षेत्र में विलय करने का मामला है (जो आवेदन से आवेदन के लिए अलग-अलग होगा, और यह आसान होना चाहिए, यदि आपके स्थानीय पहचान रिकॉर्ड में केवल कुछ ही फ़ील्ड हैं), और फिर लिंक की गई तृतीय-पक्ष पहचान सुनिश्चित करना परिणामी स्थानीय पहचान से जुड़े हैं।


1
यह एक बहुत अच्छा समाधान है (मुझे स्थानीय पहचान की टक्कर का ऑटो-डिटेक्ट करने का विचार पसंद है)! मुझे आश्चर्य है कि क्या आपने उपयोगकर्ता को "अतिरिक्त" खातों में ऑटो-लॉगिन करने का एक तरीका मिला है जो कि आवेदन में पहले लॉगिन के बाद जुड़े हुए हैं। क्या उपयोगकर्ता को हर बार आने वाले प्रत्येक खाते में अलग से लॉगिन करना होगा (यदि पहले से ही इस प्रदाता के साथ कोई सक्रिय सत्र नहीं है)?
एलेक्जेंड्रा

@ अलेक्जेंड्रा "अतिरिक्त खातों" से आपका क्या अभिप्राय है? क्या आप पूछ रहे हैं कि क्या होता है जब उपयोगकर्ता कई अलग-अलग प्रमाणीकरणकर्ताओं के माध्यम से आवेदन में लॉग करता है, प्रत्येक के साथ एक नई स्थानीय पहचान बनाता है?
चीकेन

मुझे लगता है कि यह वारंट एक उचित स्पष्टीकरण और अपना प्रश्न है: stackoverflow.com/questions/11060368/…
एलेक्जेंड्रा

3
हालांकि सवाल है, लेकिन क्या होगा यदि उपयोगकर्ता उसी ईमेल पते का उपयोग करके साइट पर पंजीकरण करता है? क्या हम उन्हें उस ईमेल का संकेत देते हैं जो पहले से मौजूद है (ईमेल जो तीसरे पक्ष के मॉडल से आया है) या हम अभी भी उन्हें साइट पर पंजीकृत करते हैं और फिर हमने उन खातों को मर्ज कर दिया है?
user962206

@ user962206 कई सेवाएँ आपको गोपनीयता कारणों से वैसे भी 'वास्तविक' ईमेल पता प्रदान नहीं करेंगी। उदाहरण के लिए, ट्विटर आपको कोई ईमेल पता नहीं देगा, जहां तक ​​मुझे पता है कि फेसबुक "user.name@facebook.com" देगा, जो मुझे संदेह है कि कोई पंजीकरण के लिए उपयोग करेगा।
kapex

44

मैं ओवरलैपिंग ज्वाइनिंग फैक्टर के रूप में ईमेल पर आधारित बहुत सारी साइटें मर्ज करने की प्रवृत्ति रखता हूं ।

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

मेरी वर्तमान विचार प्रक्रिया।

लॉगिन पेज पर 3 विकल्प हैं

  • आपकी अपनी साइट की सदस्यता
  • फेसबुक में जाये
  • Google के साथ लॉगिन करें

1) उपयोगकर्ता लॉगिन पहली बार: एक पंजीकरण प्रवाह को ट्रिगर करें जहां पहली बार एक खाता बनाया गया है और आबादी है।

 if the user logins using Facebook (or whatever 3rd party login)
      1) call the Facebook api asking for their information (email, name, etc...) 
      2) create an account membership entry in your database somewhat like this 

         Table = Users
         [ UserId   |       Email             | Password ]
         [    23     | "newuser@coolmail.com" |  *null*  ]

      3) create an external auths entry like so
         *ProviderUserId is the unique id of that user on the provider's site

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]

 if the user wants to create an account with your own registration it would just be this           

         Table = Users
         [ UserId   |       Email           |   Password  ]
         [    23     | newuser@coolmail.com |  myCoolPwd  ]

2) किसी अन्य समय में, उपयोगकर्ता वापस आता है, लेकिन Google लॉगिन पर क्लिक करने का निर्णय लेता है

      1) call the Google api asking for their information (email, name, etc...) 

      2) once you get the email, match it up to the userId entry with the existing email 

      3) create an additional External auth entry as such

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]
         [    57           |      23        |    Google    |  "1234854368"     ]

3) अब आप उस खाते में विलीन हो गए हैं, जिस पर आप भरोसा करते हैं कि आपकी डेटाबेस प्रविष्टियों पर ईमेल वही है जो आप बाहरी लॉगिन से भरोसा करते हैं।

तो बाद के लॉगिन के लिए

तो क्या हुआ अगर आपके पास पहले बाहरी लॉगिन है और फिर आप चाहते हैं कि उपयोगकर्ता बाद में पासवर्ड के साथ लॉगिन करने में सक्षम हो?

मुझे ऐसा करने के दो आसान तरीके दिखाई देते हैं

  • किसी भी बाहरी लॉगिन से खाता बनाते समय किसी भी पहले लॉगिन पर, उन्हें अपने आवेदन में अपना पहला प्रवेश पूरा करने के लिए पासवर्ड के लिए कहें

  • यदि वे पहले से ही facebook या google का उपयोग करके पंजीकरण कर चुके हैं तो किसी तरह अपनी साइट के पंजीकरण फॉर्म का उपयोग करके पंजीकरण करना चाहते हैं। पता लगाएँ कि क्या ईमेल पता जो उन्होंने पहले से ही दर्ज किया है, उनसे पासवर्ड के लिए पूछें, और पंजीकरण पूरा होने के बाद उन्हें ईमेल की पुष्टि भेजें।


1
जब आप एक बाहरी प्रमाणीकरण योजना (फेसबुक, Google, ट्विटर आदि ...) का उपयोग करते हैं, तो आप कभी भी बाहरी प्रदाता पासवर्ड तक नहीं पहुंच सकते हैं। ऊपर दिए गए उदाहरण में पासवर्ड आपके OWN वेब ऐप का पासवर्ड है।
मैक्स अलेक्जेंडर

6
ट्विटर उपयोगकर्ताओं को ईमेल की पेशकश नहीं करता है। इसलिए उनके पहले प्रमाणीकरण के बाद यदि Twitter UserId मौजूद नहीं है, तो उसे ईमेल और पासवर्ड के लिए संकेत दें। यदि ईमेल और पासवर्ड मौजूद हैं, तो खातों को लिंक करें। यदि ऐसा नहीं होता है, तो ईमेल और पासवर्ड को सहज बाद के प्रमाणीकरण के लिए संग्रहीत करें। क्या वह मददगार था?
मैक्स एलेक्जेंडर

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

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

6
यह सुरक्षा भंग है यदि कोई उपयोगकर्ता सोशल मीडिया के माध्यम से साइन अप करता है, सोशल मीडिया में अपना ईमेल पता संपादित करता है, कोई अन्य व्यक्ति उसी ईमेल पते को लेता है, जो सोशल मीडिया के साथ पंजीकृत है, और फिर लॉग इन करता है, तो उन्हें किसी अन्य खाते में विलय कर दिया जाएगा। यह बहुत संभावना नहीं है, लेकिन कोई भी उल्लंघन कम नहीं है। या क्या मैं कुछ न कुछ भूल रहा हूं।
शेन

35

मैं sled.com के साथ इसके माध्यम से गया हूँ। खाते बनाने और लॉगिन के लिए कई तृतीय-पक्ष खातों का समर्थन करने के संबंध में यहां कई समस्याएं हैं। उनमें से कुछ हैं:

  • क्या आपको स्थानीय पासवर्ड और तृतीय-पक्ष लॉगिन दोनों का समर्थन करने की आवश्यकता है?

Sled.com के लिए, मैंने स्थानीय पासवर्ड को जोड़ने के छोटे मूल्य और पासवर्ड प्रविष्टि फॉर्म हासिल करने में अतिरिक्त लागत के कारण छोड़ने का फैसला किया है। पासवर्ड तोड़ने के लिए कई ज्ञात हमले हैं और यदि आप पासवर्ड पेश करने जा रहे हैं, तो आपको यह सुनिश्चित करना चाहिए कि उन्हें तोड़ना आसान नहीं है। आपको उन्हें लीक होने से रोकने के लिए एक तरह से हैश या कुछ इसी तरह के स्टोर करने की आवश्यकता है।

  • कई तृतीय-पक्ष खातों का समर्थन करने के लिए आप कितना लचीलापन चाहते हैं?

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

स्लेज के लिए, हम फेसबुक, ट्विटर और याहू के साथ लॉगिन का समर्थन करते हैं! और प्रत्येक उपयोगकर्ता के खाते में प्रत्येक के लिए एक कुंजी संग्रहीत है: {"_id": "djdjd99dj", "याहू": "dj39djdj", ट्विटर: "3723828732", "फेसबुक": "12837287"}। हमने यह सुनिश्चित करने के लिए बाधाओं का एक समूह तैयार किया है कि प्रत्येक तृतीय-पक्ष खाते को केवल एक ही स्थानीय खाते से जोड़ा जा सकता है।

यदि आप एक ही तृतीय-पक्ष प्रदाता से कई खातों की अनुमति देने जा रहे हैं, तो आपको समर्थन देने के लिए सूचियों या अन्य संरचनाओं का उपयोग करने की आवश्यकता होगी, और उसके साथ, अन्य सभी प्रतिबंधों को विशिष्टता सुनिश्चित करने के लिए।

  • कई खातों को कैसे लिंक करें?

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

सर्वर जानता है कि यह पहली बार लॉगिन है यदि ब्राउज़र में किसी मौजूदा खाते के लिए एक सत्र कुकी (वैध या समाप्त) नहीं है, और जो तृतीय-पक्ष खाता उपयोग नहीं किया गया है। हम उपयोगकर्ता को सूचित करने का प्रयास करते हैं कि वे केवल लॉग-इन नहीं कर रहे हैं, लेकिन एक नया खाता बना रहे हैं ताकि यदि उनके पास पहले से ही एक खाता है, तो वे उम्मीद करते हैं कि वे अपने मौजूदा खाते के साथ विराम देंगे और लॉगिन करेंगे।

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

  • खातों का विलय कैसे करें?

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

यह एक बहुत ही सरल राज्य मशीन है। उपयोगकर्ता तृतीय-पक्ष खाता आईडी के साथ तीसरे पक्ष से वापस आता है। आपका डेटाबेस तीन राज्यों में से एक में हो सकता है:

  1. खाता स्थानीय खाते से जुड़ा हुआ है और कोई सत्र कुकी मौजूद नहीं है -> लॉगिन
  2. खाता स्थानीय खाते से जुड़ा हुआ है और एक सत्र कुकी मौजूद है -> मर्ज
  3. खाता किसी स्थानीय खाते से लिंक नहीं है और कोई सत्र कुकी मौजूद नहीं है -> साइनअप
  4. खाता स्थानीय खाते से लिंक नहीं है और एक सत्र कुकी मौजूद है -> अतिरिक्त खाता लिंक करना

    • तृतीय-पक्ष प्रदाताओं के साथ खाता पुनर्प्राप्ति कैसे करें?

यह अभी भी प्रायोगिक क्षेत्र है। मैंने इसके लिए एक पूर्ण यूएक्स नहीं देखा है क्योंकि अधिकांश सेवाएं तृतीय-पक्ष खातों के बगल में दोनों को एक स्थानीय पासवर्ड प्रदान करती हैं और इसलिए "मेरे पासवर्ड भूल गए" मामले पर ध्यान केंद्रित करें, बाकी सब कुछ जो गलत हो सकता है।

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


यह समाधान मेरे लिए बहुत बेहतर है, धन्यवाद!
रॉय शोए

2
उपयोगकर्ता की पहचान करने के लिए सत्र कुकी पर्याप्त नहीं है। यदि कोई अन्य उपयोगकर्ता समान डिवाइस का उपयोग करता है तो क्या होगा?
दीपबल्यू

23

ऑटो मर्जिंग खातों के लिए दोनों दृष्टिकोण एक बहुत बड़ी भेद्यता छोड़ देते हैं जो किसी को एक खाते को लेने की अनुमति देगा। वे दोनों इस धारणा को बनाने लगते हैं कि उपयोगकर्ता वह है जो वे कहते हैं कि वे एक पंजीकृत उपयोगकर्ता को मर्ज विकल्प प्रदान करते हैं।

भेद्यता को कम करने के लिए मेरी सिफारिश उपयोगकर्ता को उपयोगकर्ता की पहचान को सत्यापित करने के लिए मर्ज प्रदर्शन करने से पहले एक ज्ञात पहचान प्रदाता के साथ प्रमाणित करने का अनुरोध करना है।

उदाहरण: उपयोगकर्ता A फेसबुक पहचान के साथ रजिस्टर करता है। कुछ समय बाद वे आपकी साइट पर वापस जाते हैं और विंडोज लाइव आईडी के साथ प्रवेश करने और पंजीकरण प्रक्रिया शुरू करने का प्रयास करते हैं। आपकी साइट उपयोगकर्ता ए के साथ संकेत देगी ... ऐसा लगता है कि आपने पहले फेसबुक के साथ पंजीकरण किया है। कृपया फेसबुक (लिंक प्रदान करें) के साथ लॉगिन करें और हम आपकी विंडोज लाइव आईडी को आपके मौजूदा प्रोफाइल के साथ मर्ज कर सकते हैं।

एक अन्य विकल्प प्रारंभिक पंजीकरण पर एक साझा रहस्य (पासवर्ड / व्यक्तिगत प्रश्न) संग्रहीत करना है जो उपयोगकर्ता को पहचान को मर्ज करते समय प्रदान करना होगा, हालांकि यह आपको साझा रहस्यों को संग्रहीत करने के व्यवसाय में वापस लाता है। इसका मतलब यह भी है कि आपको उस परिदृश्य को संभालना होगा जहां उपयोगकर्ता को साझा रहस्य और उसके साथ जाने वाले वर्कफ़्लो को याद नहीं है।


यदि आप प्रदाता से ईमेल पता प्राप्त नहीं करते हैं तो आप क्या करते हैं?
fred.kassi

1

अधिकांश पद काफी पुराने हैं और मुझे लगता है कि Google की मुफ्त फायरबेस प्रमाणीकरण सेवा अभी तक नहीं थी। OAuth के साथ सत्यापन करने के बाद, आप OAuth टोकन को पास करते हैं और एक अद्वितीय उपयोगकर्ता आईडी प्राप्त करते हैं जिसे आप संदर्भ के लिए स्टोर कर सकते हैं। समर्थित प्रदाता Google, फेसबुक, ट्विटर, GitHub हैं और कस्टम और अनाम प्रदाताओं को पंजीकृत करने का विकल्प है।


ऐसे मामलों का उपयोग करने के बारे में सोचा गया है जहां फायरबेस का कोई मतलब नहीं है। उदाहरण के लिए इंट्रानेट सिस्टम जिनके पास अधिक है, एक लॉग इन करते हैं
बोसविक

0

ऊपर महान जवाब और संसाधन। मेरा योगदान यहाँ सारांशित है ... https://github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR: अलग खाता और व्यक्ति स्कीमा। खाता, ईमेल और OAuth के 2 संस्करण।

अकाउंट -ऑथेंटिकेट्स-> व्यक्ति


-4

आपको एक खाते से लॉगिन की अनुमति देनी चाहिए , फिर जब लॉग इन करने के लिए अलग-अलग दूसरे खाते को जोड़ने का विकल्प देना चाहिए।


4
और अगर उपयोगकर्ता ऐसा नहीं करता है, और 4 अलग-अलग खातों के साथ खुद को पाता है तो क्या होता है? आप एक वास्तुकला कैसे बनाते हैं जो इस मामले में विलय करने की अनुमति देता है?
डेविड बोइक

आपकी आवश्यकताओं के आधार पर यह वास्तव में एक मान्य सुझाव हो सकता है। मैं सिर्फ उन लोगों को चेतावनी देना चाहता हूं जो सोचते हैं कि खातों को विलय या लिंक करना बाद में किया जा सकता है, हालांकि: यदि आपको लगता है कि यह ऐसा कुछ है जिसे आप बाद में चाहते हैं तो आप अपने डेटाबेस डिजाइन के साथ शुरुआत में इसके लिए खुद को तैयार करना चाहेंगे: एक विकल्प के लिए एक UserGroup और एक UserMapping है। आप OAuth उपयोगकर्ता ID या ईमेल और पासवर्ड उपयोगकर्ता ID को उपयोगकर्ता समूह में मैप कर सकते हैं।
BumbleB2na
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.