ओपनआईडी का उपयोग केवल प्रमाणीकरण विधि के रूप में

Question

मैंने अन्य प्रश्न पढ़े हैं और वे ज्यादातर ऐसा करने की सुरक्षा के बारे में बात करते हैं। यह पूरी तरह से मेरी चिंता नहीं है, ज्यादातर इसलिए क्योंकि वेबसाइट एक ब्राउज़र आधारित गेम है। हालांकि, बड़ी समस्या उपयोगकर्ता है - प्रत्येक उपयोगकर्ता ओपनआईडी को समझने के लिए पर्याप्त साक्षर नहीं है। निश्चित रूप से आरपीएक्स यह बहुत आसान बनाता है, जो मैं उपयोग करूंगा, लेकिन क्या होगा यदि उपयोगकर्ता के पास Google या Facebook या जो कुछ भी खाता नहीं है, या किसी मौजूदा खाते से लॉग इन करने के लिए सिस्टम पर भरोसा नहीं करता है? उन्हें किसी अन्य प्रस्ताव पर खाता प्राप्त करना होगा - मुझे यकीन है कि अधिकांश को पता चल जाएगा कि ऐसा करने के लिए, अकेले इसे करने के लिए परेशान रहें।

एप्लिकेशन में इसे प्रबंधित करने की समस्या भी है। एक उपयोगकर्ता एक ही खाते के साथ कई पहचानों का उपयोग करना चाह सकता है, इसलिए यह उपयोगकर्ता नाम + पासवर्ड के साथ निपटने के लिए उतना आसान नहीं है। मैं डेटाबेस में किसी उपयोगकर्ता की ओपनआईडी पहचान कैसे संग्रहीत करूं? ओपनआईडी का उपयोग करके मुझे एक लाभ भी मिलता है: आरपीएक्स व्यापक प्रोफाइल जानकारी प्रदान कर सकता है, इसलिए मैं प्रोफाइल फॉर्म को फिर से भर सकता हूं और उपयोगकर्ता को आवश्यकतानुसार संपादित करने के लिए कह सकता हूं।

Users: 
------ 

ID  Email    Etc. 
--  --------------- ---- 
0  bob@yahoo.com  ... 
1  alice@yahoo.com ... 

UserOpenIDs: 
------------ 

ID  UserID  OpenID 
--  ------  ------ 
0  0   0 
1  0   2 
2  1   1 

OpenIDs: 
-------- 

ID  Provider Identifier 
--  -------- ---------------- 
0  Yahoo  https:\\me.yahoo.com\bob#d36bd 
1  Yahoo  https:\\me.yahoo.com\alice#c19fd 
2  Yahoo  https:\\me.yahoo.com\bigbobby#x75af 

इन विदेशी कुंजी के साथ

:

मैं इस समय इस राशि

UserOpenIDs.UserID -> Users.ID 
UserOpenIDs.OpenID -> OpenIDs.ID 

कि सही तरीके से डेटाबेस में OpenID पहचानकर्ताओं को संग्रहीत करने है? मैं पहचानकर्ता आरपीएक्स से कैसे मेल करूंगा, मुझे उपयोगकर्ता में लॉग इन करने के लिए डेटाबेस में एक के साथ दिया गया है (यदि पहचानकर्ता ज्ञात है)।

तो यहाँ ठोस प्रश्न हैं:

• मैं इसे एक OpenID नहीं होने उपयोगकर्ताओं के लिए पहुंच या एक का उपयोग नहीं करना चाहता कैसे होगा? (उदाहरण के लिए सुरक्षा चिंताओं, उदाहरण के लिए अपने Google खाते से लॉग इन करना)
• मैं डेटाबेस में पहचानकर्ता कैसे स्टोर करूं? (मुझे यकीन नहीं है कि उपर्युक्त सारणी सही हैं)
• किसी को किसी अन्य उपयोगकर्ता के रूप में लॉग इन करने से रोकने और अपने खाते से खुशी से कुछ करने के लिए मुझे क्या उपाय करने की आवश्यकता है? (जैसा कि मैं समझता हूं कि आरपीएक्स HTTP के माध्यम से पहचानकर्ता भेजता है, तो किसी को भी ऐसा करना होगा कि इसे किसी भी तरह से पकड़ लें, फिर इसे "ओपनआईडी" फ़ील्ड में दर्ज करें)
• ओपनआईडी का उपयोग करते समय मुझे और जानने की आवश्यकता क्या है?

Answer 1

बनाना यह सुलभ

पहले के विषय में उन है कि एक OpenID की जरूरत नहीं है, तो आप एक छोटे से पेज जो एक खाता बनाने के लिए कैसे (या यहां तक ​​कि कुछ प्रदाताओं को इंगित) बताते हैं कर सकते हैं। इस तरह, नियमित खाते की तुलना में ओपनआईडी खाता बनाना वास्तव में कठिन नहीं है।

उन लोगों के लिए जो ओपनआईडी का उपयोग नहीं करना चाहते हैं, आपके पास दो विकल्प हैं। पहला: अपने ओपनआईडी लॉगिन के बगल में एक पुराने स्टाइल लॉगिन को लागू करें और उपयोगकर्ताओं को यह चुनने दें कि वे कौन सी विधि चाहते हैं। दूसरा है केवल ओपनआईडी है ... यह आपके काम को सरल बनाता है। कह रही है जो कुछ प्रयोक्ताओं के अधिक में लॉग इन करने के लिए एक विश्वसनीय OpenID प्रदाता से एक वेबसाइट पर भरोसा है, मेरी राय में काफी अजीब ... के रूप में OpenID प्रदाता अक्सर एन्क्रिप्टेड कनेक्शन, आदि का उपयोग है

डेटाबेस में भंडारण

द्वारा प्रस्तावित स्कीमा जॉनी जी आपको जो चाहिए वह है। (मैं बस नहीं जानता कि क्यों तुम स्लैश के बजाय बैकस्लैश के साथ यूआरएल भंडारण कर रहे हैं)

आप उन्हें उपयोग करने से पहले अपने यूआरएल को सामान्य बनाने ताकि आप http://openid.test.com/abc और http://openid.test.com/abc/ जैसी चीजों से बच सकते हैं चाहते हो सकता है अलग-अलग URL के रूप में संभाला जा रहा।

अतिरिक्त उपायों

कोई नहीं लेने के लिए। आपको http://openid.net/developers/libraries से लाइब्रेरी का उपयोग करना चाहिए।

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

अगर किसी के पास आपका ओपनआईडी यूआरएल (जो सार्वजनिक है) है, तो उसे लॉग इन करने में सक्षम होने के लिए अभी भी पासवर्ड (या एक अन्य प्रकार की प्रमाणीकरण विधि जैसे एसएसएल प्रमाणपत्र) की आवश्यकता है।

Answer 2

मैं पहली बार इस सवाल का एक ही जवाब देखा:

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

Answer 3

Arg, ऊपर मेरी पिछली टिप्पणी का जवाब देने का उत्तर दें।

अपने तीसरा सवाल करने के लिए, "उपायों ... किसी अन्य उपयोगकर्ता ... के रूप में लॉग इन करने से किसी को रोकने के लिए" के रूप में मैं OpenId समझते हैं, आप कभी नहीं एक अविश्वसनीय स्रोत से एक OpenID URL स्वीकार करते हैं। कार्यान्वयन में, आपकी साइट प्रदाता के लॉगिन होस्ट करती है, प्रदाता की साइट संपर्क आपको सीधे होस्ट करती है, इसलिए आप हमेशा एक विश्वसनीय साइट से ओपनआईडी यूआरएल स्वीकार कर रहे हैं।

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

आपके दूसरे प्रश्न के लिए "मैं कैसे स्टोर करूं ..." आपकी स्कीमा काम करेगी, हालांकि यह थोड़ा आराम से दिखती है। उदाहरण के लिए, कई से कई मैपिंग का उपयोग करके [यानी UserID to OpenID] आप उपयोगकर्ता को कई ओपनआईड्स से संबंधित हैं, और एक ही ओपनआईडी कई उपयोगकर्ताओं से संबंधित हैं। आप पूर्व के बिना पूर्व चाहते हैं।

एक साधारण विदेशी कुंजी बाधा पर्याप्त होगी।

UserID  Email   
------  --------------- 
86000  bob@yahoo.com 
86001  alice@yahoo.com 

UserID  Identifier 
------  ---------------- 
86000  https:\\me.yahoo.com\bob#d36bd 
86000  https:\\me.yahoo.com\bigbobby#x75af 
86001  https:\\me.yahoo.com\alice#c19fd 

UserID परंतु Users तालिका के लिए एक विदेशी कुंजी इस अनिवार्य रूप से कहा गया है एक User मालिक शून्य या कई अद्वितीय Identifier रों है और वहाँ Identifier पर एक अद्वितीय कुंजी बाधा है। सिद्धांत रूप में, मैं शायद उस तालिका पर एक प्राथमिक कुंजी भी थप्पड़ मारूंगा, लेकिन यह ग्रेवी है।

आशा इस मदद करता है :)

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