एक पासवर्ड के बिना एक साइट में प्रवेश करने के बारे में सोच लेख

Google / Twitter / Facebook आदि के माध्यम से उपयोगकर्ता को लॉग इन करने की आवश्यकता के बारे में एक या दो बार से अधिक बार Habré पर लेख प्रकाशित किए गए हैं। दरअसल, प्रगतिशील मानवता ने लंबे समय से यह तय किया है कि उपयोगकर्ताओं को उपयोगकर्ता नाम और पासवर्ड के साथ आने की आवश्यकता है। इस लेख में मैं उभरते मुद्दों और उन्हें हल करने के तरीके पर चर्चा करना चाहता हूं।

संक्षिप्त परिचय

फिलहाल, मैं उत्साही लोगों की एक टीम में डेवलपर्स में से एक हूं, जिन्होंने कोहना php ढांचे के समुदाय के लिए एक सामाजिक नेटवर्क के तत्वों के साथ एक तरह की सूचना और संदर्भ पोर्टल लिखने का फैसला किया। एक टिप्पणी / समीक्षा लिखने, मतदान और रेटिंग में भाग लेने आदि के लिए प्रमाणीकरण आवश्यक है। OpenID / OAuth के माध्यम से इनपुट को जकड़ना आसान है, जब आप सोचना शुरू करते हैं तो दिलचस्प चीजें दिखाई देती हैं - आगे क्या है?

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

प्रमाणीकरण

डेटाबेस

हम नमूना डेटाबेस तालिकाओं को रेखांकित करते हैं जो हमें उपयोगकर्ता से अधिकतम संभव जानकारी संग्रहीत करने की अनुमति देगा जो हम खींच सकते हैं।

उपयोगकर्ताओं

यहां सब कुछ स्पष्ट है, यह उपयोगकर्ता को संग्रहीत करने के लिए मुख्य तालिका है।

• id - उपयोगकर्ता id । ऑटो वेतन वृद्धि हम अन्य साइट ऑब्जेक्ट के साथ संचार के लिए इस पहचानकर्ता का उपयोग करने की योजना बनाते हैं।
• username - साइट पर दिखाई देने वाला नाम। प्रारंभ में, हम इसे OpenID या OAuth डेटा के आधार पर उत्पन्न करते हैं, लेकिन हमें इसे बदलने का अवसर अवश्य देना चाहिए।
• email - ईमेल पता। प्रारंभ में, हम उपयोग किए गए बाहरी खाते से बाहर निकलने की कोशिश कर रहे हैं। यह हमेशा संभव नहीं है, इसलिए क्षेत्र वैकल्पिक है।

auth_data

यह तालिका बाहरी उपयोगकर्ता खातों के साथ काम करने के लिए है। उदाहरण के लिए, यदि उपयोगकर्ता A का Google पर और ट्विटर पर एक और खाता है, तो हमें उपयोगकर्ता की एक प्रविष्टि के लिए दो_ for_data प्रदान करना होगा - और ताकि कुछ भी खो न जाए!

• id - सामान्य तौर पर, सब कुछ स्पष्ट है। सिंथेटिक ऑटो-इंक्रीमेंट कुंजी।
• service_name उस प्रदाता का नाम है जिसका उपयोग लॉग इन करने के लिए किया जाता है। इसमें प्रमाणीकरण तंत्र और सेवा का वास्तविक नाम शामिल होना चाहिए। उदाहरण के लिए, यदि हम अपने livejournal खाते के तहत OpenID के माध्यम से लॉग इन करते हैं, तो हमें 'openid.livejournal' मिलता है, और 'oauth2.github' का अर्थ है हमारा Github खाता, OAuth2 E2 के माध्यम से हमारे लिए सुलभ।
• service_id - उपर्युक्त सेवा पर उपयोगकर्ता खाता पहचानकर्ता। यानी लॉगिन। सेवा_नाम के साथ जोड़ा गया service_name हमें एक अद्वितीय सूचकांक मिलता है, साइट पर ऐसे उपयोगकर्ता नहीं होने चाहिए।
• email - फिर से साबुन! इसका उपयोगकर्ता बदला नहीं जा सकता है, और हम इसका उपयोग अपने गंदे उद्देश्यों के लिए कर सकते हैं, उदाहरण के लिए, डुप्लिकेट उपयोगकर्ताओं की खोज करने या मानव लॉगिन उत्पन्न करने के लिए।
• some_data - यहां हम प्रदाता से प्राप्त अन्य सब कुछ (क्रमबद्ध रूप में) some_data देते हैं। अगर यह काम में आता है तो क्या होगा? बेशक, मैदान को बाहर फेंक दिया जा सकता है, यह मितव्ययी और कुशल मालिकों के स्कोपिडोम के लिए है ;)

संचार

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

अजीब तरह से पर्याप्त है, हम उपयोगकर्ता को कुछ खाते में बाँधने के लिए उपयोगकर्ता तालिका में auth_id विदेशी कुंजी भी जोड़ते हैं। क्यों? इस प्रकार, हम एक निश्चित प्राथमिक खाते को उजागर करना चाहते हैं। उदाहरण के लिए, स्वचालित रूप से कुछ डेटा को उपयोगकर्ता प्रोफ़ाइल में स्थानांतरित करना, या ऑटोलॉगिन लागू करना। निर्णय विवादास्पद लग सकता है, लेकिन फिलहाल हम इसे उचित और उपयोगी मानते हैं।

मुझे अंदर जाने दो!

और अब - प्रमाणीकरण तंत्र ही। कदम।

1. हमने "एन्टर थ्रू" बटन पर क्लिक किया, अपना ओपिड में प्रवेश किया, या केवल प्रदाता की तस्वीर पर क्लिक किया। प्रदाता को पुष्टि / साबित किया कि आप आप हैं।
2. प्रदाता द्वारा आपको साइट पर वापस भेजने के बाद, आपको डेटाबेस में इस उपयोगकर्ता की उपलब्धता की जांच करनी होगी। यदि आप पहले ही आ गए हैं तो क्या होगा? ऐसा करने के लिए, उपरोक्त संयोजन service_id + service_name उपयोग करें। यदि कोई खाता पाया जाता है, तो सब कुछ सरल है - हम user_id द्वारा उपयोगकर्ता को निकालते हैं और जाते हैं।
3. लेकिन नहीं, खाता पहले हमारी साइट के दायरे में नहीं आता था, इसलिए इससे पहले कि यह अपना मन बदल ले, जल्दी से इसे पंजीकृत कर लें।
   
   Cort_data में हम वह सब कुछ दर्ज करते हैं जो प्रदाता ने दिया था। इस डेटा के आधार पर, हम username बनाने की कोशिश कर रहे हैं। हम नए उपयोगकर्ता को सहेजते हैं, प्राथमिक के रूप में उपयोग किए गए खाते को निर्दिष्ट करते हैं। हुर्रे, हमारे पास एक नया उपयोगकर्ता है!

खैर, चर्चा करने के लिए क्या है?

पाब्लो, ने जल्दी से दिनचर्या का वर्णन किया, चलो विभिन्न मामलों को देखें जिन्हें प्रोग्रामर से अतिरिक्त प्रयास की आवश्यकता होती है।

मुझे याद करो!

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

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

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

क्या आपको याद है? नहीं? याद रखें!

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

वापस लौट आया। और यहाँ यह लंबे समय तक चलने वाली कुकी हमारी मदद करेगी। इसके आधार पर, हम उपयोगकर्ता को कुछ इस तरह से संकेत देते हैं, जैसे "आप Google के माध्यम से गए थे, दोस्त!"। स्वाभाविक रूप से, यदि वह एक अलग खाता पसंद करता है, तो हम कुकी को एक नए में बदल देंगे। अंत में, हम सिर्फ एक साइट हैं, हमें कोई आपत्ति नहीं है।

विभिन्न खातों से साइन इन करें

हाँ, एक अलग खाते के तहत, आप कहते हैं! तो हम उपयोगकर्ताओं की नकल करेंगे? कोई धन्यवाद नहीं। हमें इससे लड़ना चाहिए, और हम ऐसा करने के लिए हर संभव प्रयास करेंगे।

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

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

यदि उपयोगकर्ता अपने अधिकारों की पुष्टि नहीं कर सकता है, तो हौसले से बनाए गए खाते को हटा दें - हमारे लिए झूठ बोलने के लिए कुछ भी नहीं है।

मेल को देखो!

दरअसल, एक ईमेल पते को उपयोगकर्ता पहचानकर्ता के रूप में सुरक्षित रूप से उपयोग किया जा सकता है। इसलिए, भले ही कुकी न मिली हो, लेकिन प्रदाता ने हमें एक परिचित email लौटाया, हम उसी संवाद को पथ की पसंद (खाता विलय या एक नया) प्रदान करते हैं। ओह, यह अफ़सोस की बात है कि सभी खाते साबुन नहीं देते ...

आपके हाथों में झंडा!

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

गीथूब के बारे में

क्या आप जानते हैं कि Github OAuth v2 का समर्थन करता है ? और वह है, वह कर सकता है। हमारे प्रोजेक्ट के लिए, यह सेवा विशेष है, आप इसे प्रिय कह सकते हैं। जैसे ही उपयोगकर्ता Github के माध्यम से लॉग इन करता है, हम तुरंत एक अतिरिक्त चाटना शुरू करते हैं।

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

मैं किस बारे में बात कर रहा हूँ?

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