मुख्य बात पूंछ है! या ऑप्ट-आउट 2

नोट " पंजीकरण से इनकार " ने मेरे दिमाग को उत्तेजित कर दिया और मैं 2 घंटे के लिए सो नहीं सका (या रात में यह एक कप कॉफी था? ..)

मैंने पहले "सॉफ्ट" पंजीकरण, या विलंबित पंजीकरण, या "विनीत" पंजीकरण के बारे में पढ़ा था, और फिर मैंने खुद के लिए फैसला किया कि ओपनआईडी और ऐसा लगने वाला सब कुछ समाधान होगा। लेकिन जब मैं वर्तमान प्रोजेक्ट पर काम कर रहा था, तब मैंने महसूस किया कि यह मुझे बिल्कुल भी पसंद नहीं था।

निर्णय सोने से ठीक पहले आया था, और आज सुबह लागू किया गया। मैं संतुष्ट था।

लेकिन, पहली चीजें पहले।



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

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

विचारों का औपचारिककरण

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

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

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

विचार का क्रियान्वयन

मैं अपना संस्करण प्रस्तुत करता हूं।

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

• सत्र पहचानकर्ता;
• उपयोगकर्ता आईडी

हम इस तालिका में जानकारी दर्ज करेंगे यदि:

• एक नया उपयोगकर्ता बनाएं;
• वर्तमान उपयोगकर्ता की पहचान या प्राधिकार के बाद हम वर्तमान नामांकित उपयोगकर्ता के साथ सभी लाइनें अपडेट करते हैं।

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

भविष्य में OpenID को इस योजना से जोड़ने में कोई समस्या नहीं है।

अपूर्ण फ़ॉर्म सहेजने के लिए तंत्र को लागू करने के लिए, निम्न तालिका बनाएं:

• सत्र पहचानकर्ता;
• प्रपत्र प्रकार की पहचानकर्ता;
• फॉर्म से संबंधित अंतिम क्रमबद्ध पोस्ट अनुरोध।

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

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

निष्कर्ष

इसलिए, मेरे लिए पंजीकरण समस्या अब कोई समस्या नहीं है। मुझे उम्मीद है कि मेरा समाधान आपकी परियोजनाओं में उपयोगी है।

PS गर्दन, शुतुरमुर्ग और छिपकली के बारे में एक अद्भुत कार्टून यहाँ देखा जा सकता है ।

युपीडी:
मानक "स्पष्ट" पंजीकरण भी लागू किया गया है। पासवर्ड परिवर्तन और पासवर्ड रिकवरी है।

UPD2:
प्रस्तावित तंत्र का दायरा मैं किसी भी संसाधन को देखता हूं, इसकी जटिलता और पैमाने की परवाह किए बिना।

मैं समझा दूंगा। किसी भी संसाधन की सभी उपयोगकर्ता क्रियाओं को तीन श्रेणियों में विभाजित किया जा सकता है:

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

अधिकृत उपयोगकर्ताओं के साथ, सब कुछ स्पष्ट है। यह एक मानक स्थिति है।

पहचान के बारे में बहुत सारी बातें, लेकिन अधिकृत उपयोगकर्ता नहीं।

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

UPD3:

समस्या की स्थिति और उसका समाधान

मैं, बिना किसी सत्यापित ईमेल या फोन के पहचाने गए उपयोगकर्ता ने साइट पर श्रेणी 2 की कार्रवाई की। मेरे सत्र के जीवन के दौरान, अन्य 100,500 उपयोगकर्ताओं ने साइट पर श्रेणी 2 कार्रवाई (ओं) का प्रदर्शन किया।

विषय से यह इस प्रकार है कि साइट सोचती है कि एक उपयोगकर्ता, अर्थात्, मैंने इन सभी 100501 श्रेणी 2 कार्यों को किया।

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

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

इस मामले की विस्तृत चर्चा के लिए, Nail13 का विशेष धन्यवाद।