रेल्स में Devise में महारत: OmniAuth, API प्रमाणीकरण, और Authtrail

इस श्रृंखला के पहले भाग में, हमने एक उदाहरण ऐप का उपयोग करके Devise का परिचय दिया ताकि मॉड्यूल, हेल्पर्स, व्यू, कंट्रोलर, और रूट्स का पता लगाया जा सके।

इस भाग में, हम Devise के अधिक उन्नत उपयोग का पता लगाएंगे, विशेष रूप से OmniAuth, API प्रमाणीकरण, और Authtrail का उपयोग।

सीधे अंदर गोता लगाते हैं!

रूबी के लिए OmniAuth के साथ प्रमाणीकरण

आजकल, आपके सामने आने वाला लगभग हर वेब एप्लिकेशन आपको प्रमाणीकरण प्रदाताओं के विस्तृत चयन के माध्यम से लॉग इन करने का विकल्प प्रदान करेगा, जिसमें ट्विटर और फेसबुक जैसे सोशल नेटवर्क से लेकर Google, GitHub, और बहुत कुछ शामिल हैं।

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

यह विभिन्न OAuth प्रदाताओं से जुड़ने के लिए एक सरल और एकीकृत API प्रदान करता है। OmniAuth विशेष रूप से उन स्थितियों में उपयोगी है जहां आप अपने उपयोगकर्ताओं को अपने सोशल मीडिया खातों का उपयोग करके साइन अप या लॉग इन करने का विकल्प देना चाहते हैं। OmniAuth के साथ, आप अपने रेल्स एप्लिकेशन में सोशल लॉगिन कार्यक्षमता को आसानी से जोड़ सकते हैं।

जब OmniAuth का उपयोग Devise जेम के साथ किया जाता है, तो उपयोगकर्ता प्रमाणीकरण और प्राधिकरण को प्रबंधित करना और भी आसान हो जाता है। आप Devise की अंतर्निहित प्रमाणीकरण सुविधाओं का लाभ उठा सकते हैं, जबकि बाहरी प्रदाता साइन-इन विकल्पों के लिए OmniAuth का उपयोग कर सकते हैं।

OmniAuth और Devise के साथ शुरुआत करना

जैसा कि उल्लेख किया गया है, OmniAuth आपको कई थर्ड-पार्टी प्रमाणीकरण प्रदाताओं के साथ एकीकृत करने की अनुमति देता है। इस लेख के उद्देश्यों के लिए, हम GitHub का उपयोग करेंगे।

OmniAuth जेम्स इंस्टॉल करें

अपने ऐप के Gemfile में, निम्नलिखित लाइनें जोड़ें:

और यदि आप OmniAuth 2.0+ जेम का उपयोग कर रहे हैं, तो आपको यह भी जोड़ना होगा:

omniauth-rails_csrf_protection जेम यह सुनिश्चित करता है कि OAuth प्रवाह के लिए कोई भी GET अनुरोध अक्षम हैं। यह OAuth अनुरोध चरण से पहले एक रेल्स CSRF टोकन वेरिफायर भी डालता है। ये दो कार्रवाइयां OAuth प्रमाणीकरण प्रवाह को लक्षित क्रॉस-साइट फोर्जरी हमलों को कम करने के लिए हैं।

अगला, जेम्स इंस्टॉल करने के लिए bundle install चलाएं।

एक नया GitHub OAuth ऐप बनाएं

अब हमें GitHub पर एक नया OAuth ऐप बनाने की आवश्यकता है। यह ऐप प्रमाणीकरण अनुमतियों के साथ एक उपयोगकर्ता के रूप में कार्य करेगा जिसे आसानी से रद्द किया जा सकता है, यदि आवश्यक हो।

पहला कदम आपके GitHub अकाउंट प्रोफाइल के तहत सेटिंग्स पेज पर जाना है। फिर, बाएं हाथ के मेनू पर, "Developer settings" पर क्लिक करें। आप नीचे जैसी स्क्रीन देखेंगे, जहां आप एक नया OAuth ऐप बना सकते हैं:

जब आप "Register new application" पर क्लिक करते हैं, तो आपको इस तरह की स्क्रीन मिलेगी:

फॉर्म विवरण को निम्नानुसार भरें:

• एप्लिकेशन नाम - अपने नए OAuth ऐप को एक उपयुक्त नाम दें।
• होमपेज URL - अभी के लिए, https://localhost:3000/ का उपयोग करें। उत्पादन में, आप अपने ऐप के वास्तविक होमपेज URL का उपयोग करेंगे।
• एप्लिकेशन विवरण - आवश्यक नहीं, लेकिन यदि आपके पास कई ऐप हैं और उनके बीच अंतर करने की आवश्यकता है तो आप अभी भी एक रख सकते हैं।
• प्राधिकरण कॉलबैक URL - यह आवश्यक इनपुट है और आमतौर पर https://<app-url>/users/auth/<application-provider>/callback जैसे OAuth कॉलबैक URL प्रारूप का पालन करेगा। उस ने कहा, Google जैसे कुछ OAuth प्रदाता इस प्रारूप का पालन नहीं कर सकते हैं, इसलिए आपको इसका ध्यान रखना होगा।

इसके साथ, "Register application" पर क्लिक करें। निम्नलिखित स्क्रीन में, एक नया ऐप सीक्रेट जेनरेट करें और इसे कहीं सुरक्षित नोट करें (क्योंकि यह आपको केवल एक बार दिखाया जाएगा)।

Devise इनिशियलाइज़र कॉन्फ़िगर करें

Devise इनिशियलाइज़र config/initializers/devise.rb खोलें और GitHub के लिए विशिष्ट OmniAuth अनुभाग पर जाएं। यह संभवतः कमेंटेड आउट होगा, इसलिए इसे अनकमेंट करें और अपने नए GitHub OAuth ऐप के ID और सीक्रेट के साथ संपादित करें:

OmniAuth कॉलबैक कंट्रोलर बनाएं

यदि आपने पहले ही Devise कंट्रोलर जेनरेट कर लिए हैं, तो आप OmniauthCallbacksController को अपने अनुसार अनुकूलित करने के लिए तैयार पाएंगे। यदि आपका नहीं है, तो बस मैन्युअल रूप से एक बनाएं, और इसे निम्नानुसार संपादित करें:

उपरोक्त कोड के बारे में ध्यान देने योग्य कुछ बातें:

• from_omniauth एक विधि है जिसे हम अपने User मॉडल के अंदर लागू करेंगे।
• sign_in_and_redirect OAuth के अंदर एक विधि है।

User मॉडल को संशोधित करने के लिए माइग्रेशन जोड़ें

अब हमें User मॉडल में कुछ कॉलम जोड़ने की आवश्यकता है, विशेष रूप से provider कॉलम और एक uid कॉलम:

इस चरण को अंतिम रूप देने के लिए bundle exec rails db:migrate चलाएं।

Devise मॉडल को Omniauthable बनाएं

यहां, हमें अपने User मॉडल को Devise Omniauthable मॉड्यूल जोड़कर संपादित करने की आवश्यकता होगी:

इसके बाद, from_omni_auth विधि जोड़ें। इसे हमारे द्वारा अभी सेट किए गए Users::OmniauthCallbacksController से कॉल किया जाएगा:

अब हमारे पास बस एक चीज बची है: अपने Devise व्यू में लॉगिन लिंक जोड़ना।

लॉगिन लिंक सेट करें

डिफ़ॉल्ट रूप से, Devise स्वचालित रूप से उपयोगकर्ता पंजीकरण और लॉगिन व्यू में आपके लिए उपयुक्त प्रदाता का लॉगिन लिंक जोड़ देगा। यह लिंक GET विधि का उपयोग करेगा, लेकिन हम जानते हैं कि OmniAuth 2.0+ POST अनुरोध पसंद करता है। इसलिए, हमें लिंक को अक्षम करने और POST अनुरोधों का उपयोग करके अपना खुद का डालने की आवश्यकता है:

इसके साथ, हमने Devise और GitHub OAuth प्रमाणीकरण के साथ रूबी ऑन रेल्स 7 ऐप को सफलतापूर्वक सेट अप किया है। आप साथी ऐप का पूरा सोर्स कोड यहां प्राप्त कर सकते हैं।

अब, हम एक और उन्नत उपयोग के मामले में जाएंगे: API कॉल को प्रमाणित करने के लिए Devise का उपयोग करना।

रूबी के लिए Devise के साथ API प्रमाणीकरण

आज, उपयोगकर्ताओं के लिए आपके ऐप से API के माध्यम से जुड़ने की उम्मीद करना असामान्य नहीं है। इस खंड में, हम देखेंगे कि हम Devise का उपयोग करके ऐसे उपयोगकर्ता अनुरोधों को सुरक्षित रूप से कैसे प्रमाणित कर सकते हैं।

जहां ब्राउज़र-आधारित प्रमाणीकरण आमतौर पर कुकी-आधारित होता है, अधिकांश API प्रमाणीकरण JSON वेब टोकन (या केवल JWTs) के माध्यम से होता है, जिन्हें हेडर में पास किया जाता है।

टिप: इस खंड के उद्देश्यों के लिए, हम मान लेंगे कि हम रेल्स API-ओनली ऐप के साथ काम कर रहे हैं। साथ चलने के लिए, rails new app_name --api के साथ एक बनाएं

JWT-आधारित प्रमाणीकरण प्रवाह

जैसा कि हमने उल्लेख किया, API प्रमाणीकरण JWT टोकन पर आधारित है, और यह महत्वपूर्ण है कि हम समझें कि JWT-आधारित प्रमाणीकरण प्रवाह कैसे होता है। मूल रूप से, यह नीचे उल्लिखित चरणों के सामान्य क्रम का पालन करता है:

• एक उपयोगकर्ता क्लाइंट API ऐप को कॉल करता है।
• API ऐप एक JSON वेब टोकन (JWT), एक प्रमाणीकरण टोकन के साथ प्रतिक्रिया करता है जिसे कुकीज़ के स्थान पर उपयोग किया जा सकता है।
• उपयोगकर्ता क्लाइंट द्वारा बाद के अनुरोध इस टोकन का उपयोग Authorization हेडर में करके किए जाते हैं।
• उपयोगकर्ता तब Devise 'session destroy' एक्शन को हिट कर सकता है, जिसके परिणामस्वरूप टोकन का विनाश होता है और उपयोगकर्ता लॉग आउट हो जाता है।

अब, आइए इस प्रवाह को क्रिया में डालें, जिसे क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) कहा जाता है, से शुरू करते हैं।

CORS सेट करना

CORS हमारे API ऐप को बाहरी स्रोतों से अनुरोधों की अनुमति देने के लिए सेट करता है। CORS एक HTTP-आधारित सुरक्षा नीति है जो परिभाषित करती है कि बाहरी अनुरोधों को आपके एप्लिकेशन द्वारा कैसे संभाला जाएगा। डिफ़ॉल्ट रूप से, CORS किसी भी अनुरोध को ब्लॉक कर देगा जो उस डोमेन से अलग उत्पन्न होता है जिसने प्रारंभिक अनुरोध किया था (दूसरे शब्दों में, एक अलग "मूल" से आने वाला अनुरोध)।

CORS को ठीक से संभालने के लिए, हम निफ्टी जेम rack-cors का उपयोग करेंगे। Gemfile में, नीचे दी गई लाइन को अनकमेंट करें, फिर bundle install चलाएं:

इसके अलावा, एक संबंधित CORS इनिशियलाइज़र फ़ाइल खोलें और इसे नीचे के रूप में संशोधित करें:

हमने जो किया उसके बारे में कुछ महत्वपूर्ण नोट्स:

• origins "*" - इसका सीधा सा मतलब है कि हमारा API ऐप अब किसी अन्य स्रोत से अनुरोध प्राप्त कर सकता है।
• expose: %w[Authorization Uid] - डिफ़ॉल्ट रूप से, rack-cors जेम प्राधिकरण और UID हेडर को उजागर नहीं करता है, लेकिन हमें उनकी आवश्यकता है क्योंकि हम प्राधिकरण टोकन पास करेंगे।

इसके साथ, आइए Devise और साथ में Devise-JWT जेम इंस्टॉल करें।

अपने रेल्स ऐप में Devise और Devise-JWT जेम जोड़ें

devise-jwt जेम Devise का एक विस्तार है जो हमें JWT टोकन के साथ काम करने की अनुमति देगा। Gemfile में जेम्स जोड़ें, फिर bundle install चलाएं:

Devise इंस्टॉल जेनरेटर bundle exec rails g devise:install चलाएं।

मॉडल जेनरेट करें और कॉन्फ़िगर करें

हमें दो मॉडल सेट अप करने की आवश्यकता है: सामान्य Devise उपयोगकर्ता मॉडल (bundle exec rails g devise User), और एक मॉडल जिसका उपयोग हम रिवोकेशन रणनीति के लिए करेंगे (दूसरे शब्दों में, एक उपयोगकर्ता API से कैसे साइन आउट करेगा):

हम सामान्य Devise उपयोगकर्ता मॉडल को API प्रमाणीकरण के लिए JWT टोकन ऑथेंटिकेटेबल मॉड्यूल जोड़कर और टोकन रिवोकेशन रणनीति को हमारे दूसरे मॉडल, JwtDenylist का उपयोग करने के लिए परिभाषित करके संशोधित करते हैं:

अगला, हम रिवोकेशन रणनीति और उपयोग की जाने वाली रिवोकेशन टेबल को संदर्भित करके अपने दूसरे मॉडल को कॉन्फ़िगर करते हैं:

निम्नलिखित खंड में, हम टोकन रिवोकेशन और हमें इसकी आवश्यकता क्यों है, इसकी रूपरेखा तैयार करेंगे।

टोकन रिवोकेशन का महत्व

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

टोकन रद्द करते समय, हुड के नीचे वास्तव में क्या हो रहा है वह यह है कि टोकन का एक अनूठा टुकड़ा, jti (JWT ID), निकाला जाता है और परिभाषित रिवोकेशन रणनीति के अनुसार उपयोग किया जाता है।

बेशक, यह एक और सवाल उठाता है कि टोकन रिवोकेशन रणनीति क्या है। संक्षेप में, यह एक परिभाषा है कि टोकन रिवोकेशन को आपके सर्वर द्वारा कैसे संभाला जाएगा। तीन बुनियादी रिवोकेशन रणनीतियाँ हैं:

• JTIMatcher रणनीति - यहां, उपयोगकर्ता मॉडल में "jti" नामक एक अद्वितीय कॉलम जोड़ा जाता है, जो रिवोकेशन टेबल के रूप में भी कार्य करता है। जब भी कोई उपयोगकर्ता अनुरोध करता है, तो हेडर में jti संग्रहीत टोकन के खिलाफ मिलान किया जाता है और केवल तब एक्सेस की अनुमति दी जाती है जब एक मिलान पाया जाता है।
• Denylist रणनीति - इसके लिए, jti और रद्द किए गए टोकन की समाप्ति (exp) को एक डेटाबेस टेबल में संग्रहीत किया जाता है। उपयोगकर्ता द्वारा किए गए प्रत्येक अनुरोध के लिए, उपयोगकर्ता के वर्तमान टोकन jti की तुलना डेटाबेस में रद्द किए गए लोगों के खिलाफ की जाती है। यदि कोई मिलान पाया जाता है, तो उस उपयोगकर्ता के अनुरोधों को अस्वीकार कर दिया जाता है।
• Allowlist रणनीति - एक तरह से, यह रणनीति पहली रणनीति के समान है, सिवाय इसके कि यहां JWT ID को संग्रहीत करने वाली टेबल का उपयोगकर्ता टोकन को संग्रहीत करने वाली दूसरी टेबल के साथ एक-से-अनेक संबंध है। जब भी कोई अनुरोध किया जाता है, तो Allowlist टेबल में संग्रहीत उपयोगकर्ता के jti का मिलान टोकन के साथ मिलान टेबल में संग्रहीत से किया जाता है। एक्सेस केवल तभी अनुमति दी जाती है जब कोई मिलान पाया जाता है।

जाहिर है, यह टोकन रिवोकेशन का एक बहुत सरल अवलोकन है, और आप यहां इसके बारे में अधिक जान सकते हैं।

JWT टोकन के लिए एक हस्ताक्षर कुंजी सेट करें

चूंकि हम उपयोगकर्ताओं और उनके अनुरोधों को प्रमाणित करने के लिए सुरक्षित टोकन का उपयोग करेंगे, हमें उन्हें हस्ताक्षर करने का एक तरीका चाहिए। यहीं पर हमारी गुप्त कुंजी आती है। यह अनुशंसा की जाती है कि आप रेल्स गुप्त कुंजी, secret_key_base से अलग एक नई कुंजी उत्पन्न करें।

bundle exec rake secret चलाकर एक अद्वितीय कुंजी उत्पन्न करें, फिर Devise इनिशियलाइज़र को इस कुंजी को शामिल करने के लिए संपादित करें:

अंत में, आइए कंट्रोलर सेट करें।

कंट्रोलर सेट अप

Devise के लिए API प्रमाणीकरण लागू करने का अंतिम चरण हमारे कंट्रोलर सेट करना है। सरलता के लिए, हम दो कंट्रोलर सेट करेंगे: एक पंजीकरण को संभालने के लिए और दूसरा सत्र के लिए।

आइए इन्हें मैन्युअल रूप से बनाएं, पंजीकरण कंट्रोलर से शुरू करते हुए:

इस कंट्रोलर के साथ क्या हो रहा है:

• हम इसे JSON के साथ अनुरोधों का जवाब देने के लिए कॉन्फ़िगर करते हैं।
• हम एक respond_with एक्शन निर्दिष्ट करते हैं जो सफल या असफल पंजीकरण का परिणाम लौटाता है।

और अब सत्र कंट्रोलर के लिए:

पंजीकरण कंट्रोलर की तरह, यहां हम निर्दिष्ट करते हैं कि कंट्रोलर JSON के साथ प्रतिक्रिया देगा। हम एक उपयोगकर्ता के सफलतापूर्वक लॉग इन होने पर respond_with एक्शन और उपयोगकर्ता के साइन आउट को संभालने के लिए respond_to_on_destroy को भी परिभाषित करते हैं।

और इसके साथ, आपके पास Devise और JWT टोकन द्वारा संचालित एक कार्यशील API प्रमाणीकरण प्रवाह होना चाहिए!

हमारा अंतिम खंड इस पर एक त्वरित नज़र डालेगा कि आप Devise और Authtrail का उपयोग करके उपयोगकर्ता लॉगिन को कैसे ट्रैक कर सकते हैं।

Authtrail के साथ Devise लॉगिन ट्रैक करना

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

आपको उपयोगकर्ता लॉगिन को ट्रैक करने की आवश्यकता होगी, फिर उस जानकारी का उपयोग उन अधिसूचना ईमेल में करें जो आप अपने उपयोगकर्ताओं को भेजते हैं। लेकिन पहले, आपको उपयोगकर्ता लॉगिन को ट्रैक करने का एक तरीका चाहिए। यह Authtrail नामक एक निफ्टी जेम का उपयोग करके पूरा किया जा सकता है, जो Devise के साथ भी अच्छी तरह से जोड़ता है।

Authtrail इंस्टॉल करना

पहला कदम bundle add authtrail के साथ जेम इंस्टॉल करना है। इसके अलावा, चूंकि आप अपने ऐप डेटाबेस में ईमेल और IP पते जैसी उपयोगकर्ता-पहचान योग्य जानकारी संग्रहीत करेंगे, यह अत्यधिक अनुशंसा की जाती है कि आप Lockbox और Blindindex जेम्स के संयोजन का उपयोग करके उत्पादन में इस डेटा को एन्क्रिप्ट करें।

अगला, इसके इनिशियलाइज़र और लॉगिन डेटा को संग्रहीत करने वाली एक साथ वाली टेबल माइग्रेशन बनाने के लिए Authtrail जेनरेटर चलाएं:

Authtrail कैसे काम करता है

जब भी कोई उपयोगकर्ता लॉग इन करने का प्रयास करता है, तो निम्नलिखित महत्वपूर्ण विवरणों के साथ एक नया Authtrail रिकॉर्ड बनाया जाता है:

• उपयोग किया गया लॉगिन ईमेल पता
• लॉगिन सफल रहा या नहीं
• लॉगिन विफल होने का कारण (यदि लॉगिन विफल रहा)
• उपयोगकर्ता का IP पता, referrer, और बहुत कुछ

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

उपलब्ध सभी संभावनाओं को देखने के लिए Authtrail के दस्तावेज़ीकरण को देखें।

समापन

इस श्रृंखला में, हमने Devise जेम में गहराई से गोता लगाया।

सबसे पहले, हमने Devise की मूल बातें समझीं, जिसमें इसके मॉड्यूल, हेल्पर्स, व्यू, कंट्रोलर, और रूट्स कैसे काम करते हैं। इस दूसरे और अंतिम भाग में, हमने Devise को OAuth, Authtrail, और API प्रमाणीकरण के लिए कैसे उपयोग करें, इसका पता लगाया।

उम्मीद है, यह श्रृंखला Devise प्रमाणीकरण से संबंधित सभी चीजों के लिए एक उपयोगी मार्गदर्शिका के रूप में काम करेगी।

हैप्पी कोडिंग!

P.S. यदि आप Ruby Magic पोस्ट को प्रेस से निकलते ही पढ़ना चाहते हैं, तो हमारे Ruby Magic न्यूज़लेटर की सदस्यता लें और कभी भी एक भी पोस्ट न चूकें!