Database
 sql >> डेटाबेस >  >> RDS >> Database

बाहरी सेवाओं के साथ लॉग इन करना

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

बाहरी सेवा लॉगिन क्या हैं?

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

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

यहाँ वर्टाबेलो अकादमी से एक नमूना लॉगिन स्क्रीन है:

बाहरी लॉगिन कैसे काम करते हैं

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

एक प्रारंभिक बिंदु के रूप में, हम आधार के रूप में पासवर्ड पुनर्प्राप्ति और ईमेल पुष्टिकरण पर अपने पिछले लेख का उपयोग करेंगे। यहाँ इस लेख से उपयोगकर्ता-संबंधित तालिकाएँ हैं।




बाहरी लॉगिन के लिए डेटाबेस डिज़ाइन करना

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

user_account तालिका अब अपने स्वयं के प्रमाणीकरण बहीखाता पद्धति को संभालती है। user_profile तालिका वास्तविक उपयोगकर्ता जानकारी का प्रतिनिधित्व करती है:नाम, ईमेल, समय क्षेत्र, सेवा स्वीकृति की शर्तें, और इसी तरह। सभी व्यावसायिक तालिकाएं अब user_profile टेबल।

अब बाहरी खातों के लिए। OAuth प्रोटोकॉल, अंत में, हमें उनके सिस्टम में उपयोगकर्ता के लिए एक पहचानकर्ता देता है। यह पहचानकर्ता बाहरी सिस्टम में उपयोगकर्ता का नाम नहीं है। यह हमारे आवेदन के लिए सिर्फ एक पहचानकर्ता है। हमें इस आंतरिक आईडी को अपने डेटाबेस में स्टोर करना होगा। हम अशक्त कॉलम जोड़ सकते हैं facebook_id , google_id , twitter_id , आदि तालिका में user_profile . लेकिन हम कुछ अलग करेंगे।

हम नई तालिकाएँ जोड़ेंगे:facebook_account , twitter_account , google_account , जो बाहरी आईडी को स्टोर करेगा। इस तरह, यदि हमें आवश्यकता हो तो हम विशेष रूप से प्रत्येक सामाजिक वेबसाइट के लिए अतिरिक्त जानकारी जोड़ सकते हैं। यदि हम किसी अन्य सामाजिक वेबसाइट के लिए लॉगिन संभावना जोड़ना चाहते हैं, तो हमें user_profile टेबल। हम केवल एक और external_service_account टेबल।

प्रत्येक नई तालिका समान स्तंभ स्वरूप साझा करती है। उनमें से एक int . होगा user_profile_id , जो दोनों एक विदेशी कुंजी है जो user_profile तालिका और प्राथमिक कुंजी। (यह प्राथमिक कुंजी के रूप में काम कर सकता है क्योंकि हमारे सिस्टम में कोई भी दो खाते एक ही बाहरी सेवा के एकाधिक खातों से संबद्ध नहीं होने चाहिए।)

दूसरा कॉलम बाहरी खाते की आईडी होगा - facebook_id , उदाहरण के लिए। प्रत्येक facebook_id . पर एक अद्वितीय बाधा है , google_id , और twitter_id स्तंभ। हम जानते हैं कि किसी भी दो खातों को एक ही आईडी नहीं दी जाती है। वास्तव में, जब उपयोगकर्ता को बाहरी सेवा से प्रमाणित किया जाता है तो हम उनके facebook_id . को जानते हैं . जब हमें facebook_account तालिका बनाएं और सही user_profile , हम जानते हैं कि किस उपयोगकर्ता ने अभी-अभी सिस्टम में लॉग इन किया है। अगर इस आईडी के साथ कोई पंक्ति नहीं है, तो हम user_profile तालिका, और उपयुक्त खाता तालिका में एक नई पंक्ति।

यहाँ अंतिम मॉडल है:





  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. अपडेट किया गया Azure SQL डेटाबेस टियर विकल्प

  2. क्या आपका ODBC ड्राइवर उपयोगकर्ता डेटा स्रोतों का समर्थन करता है?

  3. sp_updatestats से बचने का एक और कारण

  4. SQL में प्राथमिक कुंजी कैसे बनाएं

  5. एक बहुत बड़ी मेज पर (कॉलमस्टोर) संपीड़न के साथ मज़ा - भाग 1