"एक साथ लॉग इन करें ..." को एक खाते से जोड़ने पर विचार

समस्या कथन

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

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

ऐसा लगता है, क्या अंतर है, एक साइट पर एक खाते को पंजीकृत करें, या बाहरी संसाधनों के माध्यम से लॉग इन करें?

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

स्टार वॉरियर्स - अटैक ऑफ़ द क्लोन

मैंने आपको तुरंत चेतावनी दी, यह लेख केवल विशुद्ध रूप से प्रकृति में सैद्धांतिक है, और उन सभी के विचारों और सुझावों को सुनने के उद्देश्य से बनाया गया था जिन्होंने इसे पढ़ने का फैसला किया।

समस्या का हल खोजना

उपलब्ध संसाधनों के माध्यम से एक त्वरित नज़र और सबसे आम सेवाओं के एपीआई का अध्ययन, यह पता चला था ("वाह, यह लानत के अर्थ में नहीं! लेकिन मुझे नहीं पता था!", लेकिन "अहा ... और इसलिए यह, यहाँ, और" के अर्थ में! यहां तक ​​कि, भी, ”) कि वे सभी एक ही सिद्धांत पर काम करते हैं।

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

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

खाना पकाने

मैं सामान्य शब्दों में नीचे दिए गए एल्गोरिदम का वर्णन करने का प्रयास करूंगा, लेकिन चूंकि मैं वर्तमान में कोहना ढांचे के साथ काम कर रहा हूं, इसलिए मैं गलती से इस ढांचे के संदर्भ में प्रक्रिया का वर्णन कर सकता हूं, इसलिए ज्यादा शपथ न लें।

तो, शुरुआत के लिए, हमें डेटाबेस में तीन तालिकाओं की आवश्यकता है ।

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

- यूजर आईडी
- लॉगिन (या किसी अन्य क्षेत्र, अद्वितीय, एक लॉगिन के रूप में कार्य करना)
पासवर्ड (एन्क्रिप्टेड या नहीं, अपने लिए तय करें )

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

- संसाधन आईडी
- संसाधन का नाम (उदाहरण के लिए, "Vkontakte")
- संसाधन का मशीन नाम (उदाहरण के लिए, "vkontakte")
- लिंक में उपयोगकर्ता आईडी का स्थान (उदाहरण के लिए, "vkontakte.ru/lookID}")
- इस संसाधन पर आवेदन की कुंजी (आईडी) (हमारे मामले में, हमारी साइट)

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

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

कुछ एल्गोरिदम

तो अब एक्शन ही। सबसे आसान से शुरू करते हैं!

मान लीजिए हमारे पास एक वेबसाइट है जिस पर हम पारंपरिक लॉगिन / पंजीकरण फॉर्म देखते हैं, साथ ही कुछ बाहरी संसाधनों के लिए कुछ विजेट्स के साथ सॉकेट।

जब कोई व्यक्ति हमारी साइट पर पारंपरिक रूप से लॉग इन / पंजीकरण करता है, तो अंतिम प्राधिकरण प्रक्रिया पारित करने के बाद, उसे हमारी साइट पर या तुरंत उसके पैनल पर ले जाया जाएगा, जहां वह सेटिंग्स सेक्शन को देखेगा। इस खंड में प्रवेश करने के बाद, वह वहाँ एक पैनल देखेंगे, उदाहरण के लिए, "बाहरी संसाधनों पर प्रोफाइल", जहां हमारे बाहरी संसाधनों की तालिका में फ़ील्ड बनाए जाएंगे।

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

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

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

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

इस मामले में जब कुंजियाँ मेल नहीं खाती हैं, तो यह किसी व्यक्ति की पहचानकर्ता को चोरी करने की कोशिश करने, या विनम्रतापूर्वक यह पूछने के लिए डराता है कि क्या वह अपने खाते से लॉग इन करता है या आदत से बाहर है, अपनी प्रेमिका / प्रेमी के पेज पर क्रॉल करता है।

उपरोक्त किसी भी बाहरी संसाधन के लिए सही है, जिसकी पहचान उपयोगकर्ता निर्दिष्ट करना चाहता है।

सबसे आसान विकल्प किया जाता है। हम साइट पर पंजीकरण के बिना सिस्टम के माध्यम से सबसे कठिन बात - प्राधिकरण के लिए पास करते हैं।

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

यह खाता % संसाधन नाम% साइट पर पंजीकृत किसी भी खाते से जुड़ा नहीं है। आप इसे अभी अपने खाते से लिंक कर सकते हैं, या एक नया पंजीकरण कर सकते हैं।

वास्तव में, सब कुछ इस विंडो के मुद्दे तक सीमित नहीं होगा, क्योंकि उपयोगकर्ता को खुद को एक खाते में संलग्न करने के लिए प्रेरित करने के लिए, हम उसके अधिकारों को भी काट देंगे ताकि वह उदाहरण के लिए, केवल सामग्री देख सके। खैर, या ऐसा ही कुछ और। बेशक, जब कोई व्यक्ति चेतावनी के किसी एक लिंक पर क्लिक करता है, तो वह या तो अपना लॉगिन पासवर्ड और पहचानकर्ता को दर्ज करने में सक्षम होगा जिसके तहत वह वर्तमान में साइट में लॉग इन है, स्वतः ही उसके खाते से लिंक हो जाएगा, जैसे कि पंजीकरण के मामले में।

निष्कर्ष

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

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