Omniauth और रेल पर एकल साइन-ऑन

Google या Envato जैसे पारिस्थितिक तंत्रों में उपयोगकर्ता प्रमाणीकरण को अलग-अलग सेवाओं ( account.google.com , account.envato.com ) के रूप में लागू किया जाता है जो क्लाइंट साइटों को आवश्यक डेटा और टोकन प्रदान करते हैं। रूबी ऑन रेल्स पर कुछ परियोजनाओं के विकास के दौरान, मुझे एक समान समस्या से निपटना पड़ा। वैज्ञानिक रूप से - एकल साइन-ऑन या एकल साइन-ऑन तकनीक ।

क्या जरूरत थी (1) "लॉगिन + पासवर्ड" लिंक का उपयोग करने के लिए लॉगिंग के लिए, मुख्यतः सभी सामाजिक पारिस्थितिकी तंत्र साइटों के लिए एक सामान्य सेवा थी, (2) मुख्य रूप से सामाजिक प्राधिकरण के साथ।
एक सेवा जो (3) उन सामाजिक सेवाओं से डेटा एकत्र करती है जिसके साथ उपयोगकर्ता लॉग इन करता है, और (4) यह डेटा क्लाइंट साइटों को प्रदान करता है।

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

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

सामान्य योजना

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

ग्राहक साइट

हम लोकलहोस्ट: 4000 पर चलेंगे।
Omniauth का उपयोग कर किसी भी साइट के लिए संरचना मानक है:

• Gemfile में हम omniauth और हमारी omniauth- खातों की रणनीति को जोड़ते हैं:

gem 'omniauth' gem 'omniauth-accounts' 

• बंडल स्थापित करें
• कॉन्फ़िगरेशन / इनिशियलाइज़र / omniauth.rb में, इनिशियलाइज़ेशन कोड डालें:

 Rails.application.config.middleware.use OmniAuth::Builder do provider :accounts, ENV['ACCOUNTS_API_ID'], ENV['ACCOUNTS_API_SECRET'], client_options: { site: ENV['ACCOUNTS_API_SITE'] } end 

• राऊटर.बीआरबी में, कॉलबैक विधि के लिए मार्ग जोड़ें:

 match '/auth/:provider/callback', :to => 'auth#callback' 

• हम इसमें एक कंट्रोलर और एक कॉलबैक विधि बनाते हैं, जिसमें हम request.env के माध्यम से प्राप्त करते हैं। ['omniauth.auth'] डेटा और टोकन के साथ अंतिम हैश

 rails g controller auth --skip-assets # auth_controller.rb class AuthController < ApplicationController def callback auth_hash = request.env['omniauth.auth'] render json: auth_hash end end 

वह सब, न्यूनतम रूप से।

रणनीति

मानक oauth 2.0 रणनीति से व्युत्पन्न, ओमनीथ-ओउथ 2 निर्भरता Gemspec में निर्दिष्ट है। बहुत कम कोड है, इसके अलावा, इसे अपने लिए समायोजित करने का कोई मतलब नहीं है, सभी आवश्यक रणनीतियों को आरंभीकरण मापदंडों (उदाहरण के लिए, पर्यावरण चर के रूप में) में प्रेषित किया जाता है। यह है:

• क्लाइंट साइट के साइट प्रदाता से कनेक्ट करने के लिए क्रेडेंशियल कीज़ (ACCOUNTS_API_ID और ACCOUNTS_API_SECRET)
• प्रदाता साइट का पता ACCOUNTS_API_SITE
• प्रदाता साइट पर प्रमाणीकरण पता (डिफ़ॉल्ट: / प्राधिकृत) ।।
• ... और टोकन पाने के लिए (/ टोकन)

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

वेबसाइट प्रदाता

हम लोकलहोस्ट: 3000 पर चलेंगे।
दो हिस्सों को जोड़ती है:

• एक ग्राहक साइट के साथ संवाद करने के लिए है
• एक अन्य सामाजिक सेवाओं के साथ संवाद करने के लिए है।

प्रदाता साइट पर प्रमाणीकरण मानक ओम्निथ्य रणनीतियों का उपयोग करके किया जाता है।
एक कस्टम साइट पर प्रमाणीकरण - एक कस्टम रणनीति का उपयोग करना।

साझा लिंक - खाता:

• प्रदाता साइट पर प्रवेश के तरीके इसके लिए बंधे हैं (हब पर एक हाउसकीपर की तरह)
• क्लाइंट साइटों के लिए एप्लिकेशन और अनुदान भी इसके लिए बंधे हैं।

प्रदाता साइट प्रमाणीकरण और खाता प्रबंधन

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

यह विषय पहले ही हबर के पन्नों पर फिसल गया। दुर्भाग्य से, मैं अभी इस लेख को नहीं पा सकता हूं, लेकिन विशेष रूप से, साइट पर सामाजिक प्रमाणीकरण के साथ विशिष्ट समस्याओं के बारे में सवाल उठाया गया था:

• खाता मर्ज विकल्प
• सेवाओं में इसे अपडेट करते समय खाता डेटा अपडेट करना
• विभिन्न सेवाओं को एक खाते में बाँधने की क्षमता

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

खाता मर्ज

हम gmail-box के माध्यम से सिस्टम में गए - सिस्टम ने gmail के डेटा के साथ एक खाता बनाया। अगली बार जब वे फेसबुक के माध्यम से लॉग इन हुए, और सिस्टम ने फिर से एक नया खाता बनाया। हम देखते हैं और समझते हैं कि पिछली बार हमने अपने लिए एक खाता बनाया था ... याद रखें ... जीमेल! हम बटन पर क्लिक करते हैं, इस बार हम जीमेल के माध्यम से जाते हैं और हमारे खाते एक में विलीन हो जाते हैं - ठीक दो पैसे की तरह! .. या नहीं - एक समस्या है। डेटा मर्ज।

जीमेल में हम अलेक्जेंडर पोलोविन हैं, और फेसबुक पर हम एलेक्स पोलोविन हैं। और मुझे अपने खाते में क्या डेटा छोड़ना चाहिए?

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

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

 { name: [' ', 'Alex Polovin', ' '], first_name: ['', 'Alex', ''], sir_name: ['', 'Polovin'], ... } 

जैसा कि आप देख सकते हैं, मूल्यों को प्रत्येक क्षेत्र के लिए सरणी में जोड़ा जाता है। हालांकि, उन्हें डुप्लिकेट नहीं किया गया - ट्विटर से "हाफ" को "अंतिम नाम" में डुप्लिकेट के रूप में सहेजा नहीं गया था।

ग्राहक साइटों को हमेशा सरणियों से बहुत पहले मूल्य प्राप्त होगा, यदि वांछित है, तो उपयोगकर्ता किसी भी मूल्य को पहली जगह में रख सकता है।

खाता जानकारी अपडेट करें

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

विभिन्न सेवाओं को एक खाते से जोड़ना

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

खाता क्षेत्रों का मैन्युअल संपादन

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

कार्यान्वयन

आदर्श

• खाता - डेटा हैश (जानकारी) संग्रहीत करता है
• प्रमाणीकरण - प्रमाणीकरण फेसबुक, ट्विटर, या किसी अन्य सेवा पर omniauth के माध्यम से किया जाता है; प्रदाता और उपयोगकर्ता के नाम को संग्रहीत करता है;

क्रम को जानकारी को हैश के रूप में समझने के लिए: टेक्स्ट फ़ील्ड का प्रकार माइग्रेशन में निर्दिष्ट है, और कोड मॉडल में जोड़ा गया है:

 serialize :info, Hash 

मॉडल के बीच - एक-से-कई संबंध:

 # /app/models/account.rb has_many :authentications # /app/models/authentication.rb belongs_to :account 

नियंत्रकों

प्रमाणीकरणकंट्रोलर में सभी प्रमाणीकरण जरूरतों को शामिल किया गया है, जिसमें निम्नलिखित क्रियाएं शामिल हैं:

• (डेटा) लॉग इन या प्रोफाइल डेटा अपडेट करने के लिए सेवा चुनने के लिए पृष्ठ
• logout (/ logout) - लॉगआउट
• कॉलबैक (/ सामान्य /: प्रदाता / कॉलबैक) - इस पद्धति में, मुख्य काम दर्ज करने, डेटा अपडेट करने, बाइंडिंग प्रमाणीकरण, और इसी तरह किया जाता है।
• विफलता (/ सामान्य / विफलता) - यदि दर्ज करते समय "दूसरे छोर" पर कोई त्रुटि हुई तो निष्पादित
• detach (/ Ord / detach) - चालू खाते से प्रमाणीकरण काट देता है

प्रमाणीकरण सेवाओं में से एक का चयन करते समय, ओम्नियाथ के लिए मानक संचालन किया जाता है - सफल प्रमाणीकरण के मामले में, मुकुट कॉलबैक विधि कॉल है। स्थिति के आधार पर, यह निम्नलिखित क्रियाएं करता है:

• प्रोफाइल डेटा अपडेट करता है
• दो अलग-अलग खातों को एक साथ जोड़ता है
• चालू खाते में एक नई सेवा को बांधता है
• पुनः लॉगिन या प्राथमिक लॉगिन

चयनित सामाजिक नेटवर्क के आधार पर डेटा हैश एक अलग निजी विधि get_data_hash () में बनता है। सेवा।

डुप्लिकेट के बिना सरणियों के अंत में डेटा जोड़ने के लिए, add_info मॉडल विधि का उपयोग करें (सरणियों के संयोजन के संचालन के आधार पर):

 def add_info(info) self.info.merge!(info){|key, oldval, newval| [*oldval].to_a | [*newval].to_a} end 

और प्रामाणिकताओं को जोड़ने के लिए add_authentication:

 def add_authentications(authentications) self.authentications << authentications end 

नतीजतन, सत्र उस खाते की आईडी को बचाता है जिसके लिए यह लॉग इन किया गया था - सत्र [: account_id]।

इस चरण में AccountController में निम्नलिखित क्रियाएं शामिल हैं:

• सूचकांक - प्रपत्र में उपयोगकर्ता प्रोफ़ाइल
• संपादित करें - खाता प्रोफ़ाइल डेटा संपादित करें
• अद्यतन - प्रोफ़ाइल अपडेट करें (संपादन से POST अनुरोध)

और एक फिल्टर - नेटवर्क पर एक उपयोगकर्ता की उपस्थिति के लिए एक अनिवार्य जांच (प्रवेश लॉगिन पृष्ठ पर रीडायरेक्ट के साथ)।

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

• यदि js अक्षम है - एक YAML- स्वरूपित हैश के साथ एक पाठ क्षेत्र है
• सक्षम होने पर, jsoneditor json संरचनाओं का दृश्य संपादक लोड किया जाता है

क्लाइंट साइट और प्रदाता साइट के बीच एक लिंक बनाना

इस मामले में, मानक अभ्यास प्रदाता वेबसाइट पर एक "एप्लिकेशन" बनाना है। हम क्लाइंट साइट का नाम और पता इंगित करते हैं (या बल्कि कॉलबैक रीडायरेक्ट के लिए पता) - और हमें दो कुंजी मिलती हैं - आईडी और गुप्त। हम उन्हें सामाजिक प्रमाणीकरण प्रणाली के मापदंडों में संकेत देते हैं - यह किसी भी सेमी प्लगइन, या रेल के लिए रत्न हो। हमारे मामले में, चाबियाँ omniauth - ACCOUNTS_API_ID और ACCOUNTS_API_SECRET द्वारा उपयोग की जाती हैं।

एक वेबसाइट प्रदाता में आवेदन समर्थन को लागू करना आसान है:

 rails g scaffold Application name:string uid:string secret:string redirect_uri:string account_id:integer rake db:migrate # account.rb has_many :applications 

एक नया रिकॉर्ड बनाते समय, मॉडल को इसके लिए कुंजी उत्पन्न करनी चाहिए:

 before_create :default_values def default_values self.uid = SecureRandom.hex(16) self.secret = SecureRandom.hex(16) end 

और - आवेदन पर सभी कार्यों में वर्तमान उपयोगकर्ता द्वारा फ़िल्टर किया जाना चाहिए। उदाहरण के लिए, इसके बजाय:

 @applications = Application.all 

द्वारा उपयोग किया जाता है:

 @applications = Account.find(session[:account_id]).applications 

इसके अलावा - यह सुनिश्चित करने के लिए जरूरी है कि उपयोगकर्ता ऑनलाइन है - एक फिल्टर लगाएं:

 before_filter :check_authentication def check_authentication if !session[:account_id] redirect_to auth_path, notice: '    ,    .' end end 

प्रक्रिया आरेख

प्रमाणीकरण oauth 2.0 पर बनाया गया है - आप हब पर, या स्पष्ट रूप से इस लेख में इस प्रोटोकॉल के सिद्धांतों के बारे में जान सकते हैं।

शुरुआती बिंदु पता क्लाइंट- site.com/auth/accounts है। ओमनियाथ इसे उठाता है और, ओमनीथ-अकाउंट्स रणनीति का उपयोग करते हुए, प्रदाता की साइट के सर्वर के लिए एक अनुरोध भेजता है।

एक ही समय में, ओम्नियुथ राज्य पैरामीटर उत्पन्न करता है, जो प्रदाता को एक ग्राहक साइट और अन्य अनुरोधों के साथ उपयोगकर्ता से अनुरोध को भ्रमित न करने में मदद करता है।

वेबसाइट प्रदाता अनुरोध स्वीकार करता है (मानक, प्रदाता- site.com/authorize पर), और कुछ कार्य करता है। इस स्तर पर प्रदाता का लक्ष्य उपयोगकर्ता को अधिकृत करना और उसे ग्राहक की साइट पर प्रमाणीकरण के लिए अनुदान देना है।

यदि लक्ष्य प्राप्त किया जाता है, तो प्रदाता की वेबसाइट से क्लाइंट साइट के कॉलबैक विधि पर रीडायरेक्ट भेजा जाता है, जहां request.env ['omniauth.auth'] के माध्यम से हमें प्रदाता की साइट से टोकन और डेटा के साथ एक हैश मिलता है।

प्राधिकरण

प्राधिकरण विधि प्रक्रिया योजना में सबसे अंधेरी जगह है - उपयोगकर्ता को अनुदान देने से पहले विचार करने के लिए बहुत सारी बारीकियां हैं।

आदर्श रूप से (दोहराया प्राधिकरण के साथ) - निम्नलिखित शर्तें पूरी की जाती हैं:

• उपयोगकर्ता पहले ही प्रदाता साइट पर लॉग इन कर चुका है
• उपयोगकर्ता को पहले ही इस आवेदन के लिए अनुदान दिया जा चुका है
• यह अनुदान समाप्त नहीं हुआ है

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

यदि इनमें से कम से कम एक स्थिति पूरी नहीं हुई है, तो आपको पहले समस्याओं का समाधान करना होगा:

• यदि उपयोगकर्ता प्रदाता की वेबसाइट पर लॉग इन नहीं हुआ है, तो उसे करने दें
• यदि अनुदान जारी नहीं किया गया है, तो इसे बनाएं।
• यदि अनुदान समाप्त हो गया है, तो अनुदान को फिर से बनाएं

इन कार्यों में साइट प्रदाता और यहां तक ​​कि सोशल साइट्स को नेविगेट करना शामिल है। सेवाएं (यदि उपयोगकर्ता को लॉग इन करने की आवश्यकता है)। अंतिम कारण पर प्रकाश डाला गया - इस जगह में ओम्नियाथ अपने अप्रिय पक्षों को दर्शाता है।

तथ्य यह है कि ओम्निथ, जब अधिकृत करने के लिए स्विच हो रहा है, तो कई मापदंडों को url से गुजरता है, और प्रदाता साइट के सत्र में कई मापदंडों को भी निर्धारित करता है। यह उसके लिए आवश्यक है कि कॉलबैक पद्धति को सही ढंग से पुनर्निर्देशित करे। लेकिन अगर हम अचानक एक प्रदाता साइट पर ओम्निथ का उपयोग करना चाहते हैं (उदाहरण के लिए, जब एक सामाजिक सेवा के माध्यम से लॉग इन करने की कोशिश कर रहे हैं), तो ऑम्नियाथ सत्र से अपने डेटा को मिटा देगा। और रीडायरेक्ट त्रुटि के साथ विफल हो जाएगा OmniAuth :: रणनीतियाँ :: OAuth2 :: CallbackError - अमान्य_credentials।

इसलिए, ऐसी स्थितियों से बचने के लिए, सत्र में सभी omniauth पैरामीटर स्पष्ट रूप से तय किए जाते हैं और पुनर्निर्देशन से ठीक पहले बहाल किए जाते हैं।

आदेश # रजिस्टर

यदि सभी मापदंडों को सही तरीके से प्रेषित किया जाता है (जो कि, omniauth से अनुरोध आया है) - वर्तमान सत्र में एक रिकॉर्ड बनाएं - "अनुदान आदेश" और इसमें सभी मापदंडों को सहेजें:

 session[:grants_orders] = Hash.new if !session[:grants_orders] session[:grants_orders].merge!( params[:client_id] => { redirect_uri: params[:redirect_uri], state: params[:state], response_type: params[:response_type], 'omniauth.params' => session['omniauth.params'], 'omniauth.origin' => session['omniauth.origin'], 'omniauth.state' => session['omniauth.state'] } ) 

आदेश # शो

हम यहां सभी जांच करते हैं। क्या उपयोगकर्ता ऑनलाइन है, क्या उस साइट पर एक आवेदन पंजीकृत है जहां से अनुरोध आया था, क्या कोई पुराना अनुदान है, क्या यह समाप्त हो गया है।

• यदि सब कुछ क्रम में है, तो हम तुरंत अनुदान विधि कहते हैं
• अगर कुछ गलत है, तो हम पृष्ठ को ऐसी प्रमाणिकता के लिए विशिष्ट दिखाते हैं ("आवेदन खाते में पहुंच का अनुरोध कर रहा है", "अनुमति दें", "अस्वीकार करें")

आदेश # स्वीकार करते हैं

यदि अनुदान तत्काल उपलब्ध था और आवश्यकताओं के मिलान से या अनुदान आदेश पृष्ठ पर "अनुमति दें" बटन पर क्लिक करके इसे निष्पादित किया जाता है।

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

आदेश # इनकार

हम एप्लिकेशन को रद्द करते हैं, बस इसे सत्र से हटा दें।

अनुदान # टोकन

पारित मापदंडों के अनुसार, हम आवेदन और अनुदान पाते हैं। यदि सब कुछ क्रम में है, तो हम अनुदान प्रारूप में टोकन जारी करते हैं।

खाते # get_info

हम हैश को json प्रारूप में लौटाते हैं, जैसा कि सहमत है - केवल पहला पैरामीटर मान, यदि उन्हें किसी सरणी द्वारा दर्शाया गया है।

 data_hash = grant.account.info hash = Hash.new hash['id'] = grant.account.id data_hash.each do |key, value| if value.kind_of?(Array) hash[key] = value[0] else hash[key] = value end end render :json => hash.to_json 

निष्कर्ष

समाधान सरल हो गया - और इसमें, निश्चित रूप से, बहुत सुधार और अनुकूलित किया जा सकता है। निम्नलिखित कार्य वर्तमान में उल्लिखित हैं:

• एक आवेदन पत्र बनाने के लिए एक अवसर देने के लिए यह इंगित करने के लिए कि कौन से मापदंडों की आवश्यकता है यह अनिवार्य और वैकल्पिक है। और, यदि आवश्यक पैरामीटर उपयोगकर्ता की प्रोफ़ाइल में नहीं हैं - तो उसे सीधे अनुदान रसीद पृष्ठ पर दर्ज करने का अवसर दें
• एक उपयोगकर्ता नाम + पासवर्ड लिंक के साथ लॉगिन प्रदान करें - omniauth- पहचान रणनीति का उपयोग कर
• न केवल क्लाइंट साइट पर, बल्कि प्रदाता साइट पर भी लॉग आउट करने वाले क्लाइंट साइट पर एक लॉगआउट कार्रवाई जोड़ें
• एक लापता सत्र के साथ समस्या को हल करें toson और get_info json रिक्वेस्ट (यह किसी तरह रेल सुरक्षा प्रणाली से संबंधित है, protect_from_forgery और verify_authenticity_token से संबंधित है)

हर दिन आपको ऐसी प्रणाली नहीं लिखनी है - क्योंकि, वास्तव में, इंटरनेट पर इतने सारे पारिस्थितिकी तंत्र नहीं हैं। Google, Envato, Yandex, Yahoo - और कौन है? शायद आपका प्रोजेक्ट? और यह संबंधित परियोजनाओं में प्रमाणीकरण को लागू करने का एकमात्र तरीका नहीं है - सीएएस तकनीक (उपयोगी लिंक के एक जोड़े) है, वहाँ ओपनआईडी है (और, एक विकल्प के रूप में, वही लॉगिन)। हमारे स्वयं के हब्र और अन्य टीएम परियोजनाओं पर - सामान्य रूप से, प्रत्येक साइट पर एक अलग प्रमाणीकरण प्रणाली है, साथ ही मालिकाना "कीमास्टर"।

मेरी पसंद एसएसओ पर क्यों गिरी? शायद कुंजी "के लिए" वातावरण है। ये वे भावनाएँ हैं जो उपयोगकर्ता को तब अनुभव होती हैं जब वह साइट पर नहीं, बल्कि सिस्टम में लॉग इन करता है - एक पूंजी "C" के साथ। एक शक्तिशाली, उन्नत, विकसित प्रणाली में - यह वास्तव में एक अद्भुत भावना है, सहकर्मियों।