रूबी प्राधिकरण में महारत हासिल करना:पंडित बनाम कैनकैनकैन
<पी> आज, कई वेब एप्लिकेशन में ऐसे पेज होंगे जो सार्वजनिक रूप से उपलब्ध हैं - जैसे होमपेज - और अधिक सुरक्षित जहां उपयोगकर्ता को पहुंच प्राप्त करने के लिए लॉग इन करना होगा। उपयोगकर्ता पंजीकरण, लॉग इन और उपयोगकर्ता सत्र स्थिति को ट्रैक करने की प्रक्रिया को "प्रमाणीकरण" कहा जाता है। <पी> साथ ही, लॉग-इन उपयोगकर्ताओं के साथ व्यवहार करते समय, उनकी उपयोगकर्ता भूमिकाओं के आधार पर उनके लिए उपलब्ध कार्यों और संसाधनों को अलग करना आवश्यक है। उदाहरण के लिए, "एडमिन" के पास आम तौर पर सामान्य उपयोगकर्ताओं की तुलना में अधिक पहुंच होती है। प्रमाणित उपयोगकर्ता पहुंच को अलग करने की इस प्रक्रिया को "प्राधिकरण" कहा जाता है। <पी> इस पोस्ट में, हम रूबी में अब तक की दो सबसे लोकप्रिय प्राधिकरण लाइब्रेरीज़ का पता लगाएंगे:पंडित और कैनकैनकैन। <पी> आइए गोता लगाएँ! सेटअप और पूर्वापेक्षाएँ
<पी> इस लेख में, हम उपयोगकर्ताओं और पोस्टों को प्रदर्शित करने वाले एक सरल रेल 7 ऐप का उपयोग करेंगे। उपयोगकर्ताओं को "संपादक" या "लेखक" की भूमिका सौंपी जाएगी। ऐसा परिदृश्य यह दिखाने के लिए बिल्कुल उपयुक्त है कि प्राधिकरण कैसे काम करता है। <पी> हमारे उदाहरण ऐप के लिए कोड रिपोज़ देखें:
<पी> भले ही यह लेख प्राधिकरण पर केंद्रित है, प्रमाणीकरण के सहयोगी विषय को नजरअंदाज नहीं किया जा सकता है। <पी> हम प्रमाणीकरण स्थापित करने के विवरण में नहीं जाएंगे क्योंकि यह इस पोस्ट के दायरे से बाहर है। आप डेविस रत्न दस्तावेज़ीकरण में इंस्टॉलेशन निर्देशों का पालन कर सकते हैं (हम डेविस को हमारे प्राधिकरण रत्नों के साथ जोड़ देंगे)। <पी> एक और बात - चाहे आप पंडित या कैनकैनकैन से निपटें, आपके ऐप की उपयोगकर्ता भूमिकाओं को परिभाषित करने का वास्तविक कार्य स्वचालित रूप से तब नहीं होता है जब आप प्राधिकरण रत्नों में से किसी एक को इंस्टॉल करते हैं। आपको इसे मैन्युअल रूप से सेट करना होगा। <पी> आइए ऐसा करें। उपयोगकर्ता भूमिकाएँ परिभाषित करना
<पी> आइए मान लें कि आपने पहले ही डेविस रत्न स्थापित कर लिया है और एक उपयोगकर्ता मॉडल स्थापित कर लिया है। अगला कदम यह तय करना है कि ऐप के उपयोगकर्ताओं की क्या भूमिकाएँ होंगी। हमारे मामले में, हम निम्नलिखित भूमिकाएँ निर्धारित करेंगे: - लेखक - यह उपयोगकर्ता भूमिका बनानेमें सक्षम होगी , संपादित करें , अद्यतन , और हटाएं उनके अपने पोस्ट. साथ ही एक लेखक देख भी सकता है अन्य लेखकों की पोस्ट.
- संपादक - संपादक की भूमिका वाला उपयोगकर्ता संपादन कर सकता है , अद्यतन , देखें , और हटाएं किसी भी उपयोगकर्ता की पोस्ट, लेकिन वे बना नहीं सकते उनकी अपनी पोस्ट.
<पी> उपयोगकर्ता की भूमिका संग्रहीत करने के लिए एक कॉलम जोड़ें (उपयोगकर्ता की तालिका को संशोधित करने के लिए माइग्रेशन का उपयोग करके): <पी> फिर माइग्रेशन चलाएँ: <पी> और फिर उन भूमिकाओं को शामिल करने के लिए उपयोगकर्ता मॉडल को संशोधित करें जिन्हें हमने अभी परिभाषित किया है: <पी> जब तक हम इस पर हैं, आइए आगे बढ़ें और एक Post सेट करें title की विशेषताओं वाला मॉडल और body , साथ ही पोस्ट लिखने वाले उपयोगकर्ता का संदर्भ: <पी> हम विदेशी कुंजी user_id जोड़ते हैं Post में किसी विशेष उपयोगकर्ता के साथ बनाई गई प्रत्येक पोस्ट को संबद्ध करने के लिए मॉडल। चूँकि हमने पहले ही डेविस का उपयोग करके उपयोगकर्ता प्रमाणीकरण स्थापित कर लिया है, हम बस Posts की निर्माण विधि को संशोधित कर सकते हैं। नियंत्रक स्वचालित रूप से user_id सेट करने के लिए वर्तमान में लॉग-इन उपयोगकर्ता के लिए: <पी> हम यह सुनिश्चित करने के लिए उपयोगकर्ता मॉडल को संशोधित भी कर सकते हैं कि यह Post से संबद्ध है मॉडल: <पी> अंत में, चलिए डेटाबेस को कुछ उपयोगकर्ताओं के साथ जोड़ते हैं, प्रत्येक की अलग-अलग भूमिका होती है: <पी> फिर डेटाबेस को सीड करें: <पी> अब तक, हमारे ऐप में अब है: - Devise का उपयोग करके प्रमाणीकरण सेट किया गया।
- "लेखक" और "संपादक" की दो परिभाषित उपयोगकर्ता भूमिकाएँ।
- ए
Post मॉडल.
<पी> इसके साथ, अब हमारे पास पंडित के साथ ठीक से काम करने के लिए आवश्यक सभी चीजें हैं। पंडित के साथ आपके रूबी ऐप में प्राधिकरण
<पी> पंडित एक प्राधिकरण पुस्तकालय है जो ऑब्जेक्ट-ओरिएंटेड आर्किटेक्चर और सादे रूबी कक्षाओं के आसपास बनाया गया है। यह आपको एक ठोस प्राधिकरण परत बनाने के लिए उपकरण देता है जो आपके ऐप के साथ स्केल कर सकता है। अपने रूबी ऐप में पंडित इंस्टॉल करना
<पी> रत्न को अपने ऐप के Gemfile में जोड़ें: <पी> फिर टर्मिनल में, कमांड चलाएँ: <पी> वैकल्पिक रूप से, निम्न आदेश चलाएँ: <पी> चूंकि प्राधिकरण ज्यादातर नियंत्रक संसाधनों तक पहुंच देने या अस्वीकार करने से संबंधित है, अगला कदम पंडित के प्राधिकरण मॉड्यूल को एप्लिकेशन नियंत्रक में जोड़ना है: <पी> और अंत में, एक आधार नीति वर्ग तैयार करें जो अन्य सभी नीतियों को विरासत में मिलेगी: <पी> जो आपको निम्नलिखित आधार नीति वर्ग देता है: <पी> इसके साथ, पंडित अब ठीक से स्थापित हो गया है और जाने के लिए तैयार है। इसके अतिरिक्त, हमारे पास प्रमाणीकरण और उपयोगकर्ता भूमिकाएँ स्थापित हैं। <पी> इसके बाद, आइए उन नियमों को लागू करने के लिए नीतियों का उपयोग करें जो परिभाषित करते हैं कि प्रत्येक उपयोगकर्ता की भूमिका Post तक कैसे पहुंचेगी संसाधन. पंडित नीतियों को कॉन्फ़िगर करना
<पी> पंडित भाषा में, "नीति" एक सादा रूबी वर्ग है जहां आप उपयोगकर्ता की भूमिका विभिन्न संसाधनों के साथ कैसे इंटरैक्ट करती है, इसके लिए सभी नियमों को परिभाषित करते हैं। <पी> ये नीतियां कुछ उल्लेखनीय विशेषताओं के साथ आती हैं: - प्रत्येक पॉलिसी का नाम मौजूदा मॉडल के नाम पर रखा गया है, जिसके साथ "पॉलिसी" शब्द जुड़ा हुआ है। उदाहरण के लिए, एक नीति यह परिभाषित करती है कि
Post जिस मॉडल को एक्सेस किया जाता है उसे PostPolicy कहा जाता है .
- एक
attr_reader :इसमें दो तर्क लगते हैं - पहला एक user है , विशेष रूप से, वर्तमान में लॉग-इन उपयोगकर्ता - current_user - और दूसरा तर्क वह मॉडल है जिसके लिए आप प्राधिकरण नियमों को परिभाषित करना चाहेंगे, हमारे मामले में, post .
- क्वेरी विधियां जो उस संसाधन के नियंत्रक तरीकों को मैप करेंगी जिनके पास प्राधिकरण नियम स्थापित हैं। संगठनात्मक उद्देश्यों के लिए, सभी नीतियों को
app/policies के अंतर्गत रखना सर्वोत्तम है फ़ोल्डर.
<पी> चूँकि हम जानते हैं कि हमें अपने ऐप में विभिन्न उपयोगकर्ता भूमिकाओं के लिए किन एक्सेस नियमों को परिभाषित करने की आवश्यकता है, आइए लेखक की भूमिका से शुरू करें। किसी भूमिका के लिए पंडित नीति को परिभाषित करना
<पी> आइए लेखक की भूमिका का उपयोग करके देखें कि यह कैसे किया जा सकता है। आरंभ करने के लिए, हम Post तक लेखक की भूमिका की पहुंच की रूपरेखा तैयार कर सकते हैं संसाधन इस प्रकार है: - बनाएं उनके अपने पोस्ट
- संपादित करें और अद्यतन करें उनके अपने पोस्ट
- देखें (या पढ़ें) उनकी अपनी पोस्ट के साथ-साथ अन्य उपयोगकर्ताओं की पोस्ट
- हटाएं उनके अपने पोस्ट
<पी> इसे ध्यान में रखते हुए, आगे बढ़ें और पोस्ट तक पहुंचने के तरीके को नियंत्रित करने के लिए एक नई नीति तैयार करें: <पी> यह हमें निम्नलिखित सामान्य नीति वर्ग देता है जो हमारे द्वारा पहले बनाई गई आधार नीति से प्राप्त होता है: <पी> आइए अब तदनुसार लेखक की भूमिका के लिए एक्सेस नियम जोड़ें (ये आधार नीति वर्ग से विरासत में मिले किसी भी नियम को ओवरराइड भी करते हैं): <पी> यहां, हम परिभाषित करते हैं कि एक लेखक पोस्ट बनाते, संपादित करते, अपडेट करते और हटाते समय क्या कर सकता है, जो पोस्ट के नियंत्रक पर संबंधित क्रियाएं हैं। यदि आपने ध्यान दिया हो, तो ये नियम सामान्य रूप से पोस्ट पर लागू होते हैं और जरूरी नहीं कि लेखक की अपनी पोस्ट पर भी (हम इस पर स्कोप अनुभाग में चर्चा करेंगे)। <पी> फिलहाल, आइए देखें कि हम इस नीति का उपयोग कैसे कर सकते हैं। पंडित में एक नीति का उपयोग करना
<पी> पॉलिसी का उपयोग करने के लिए, पंडित के authorize पर कॉल करें नियंत्रक की विधि पर विधि जहां आप पहुंच नियमों की जांच करना चाहते हैं। आप प्रासंगिक नीति वर्ग और, अधिक विशेष रूप से, वह कार्रवाई शुरू करते हैं जिसे authorize के आधार पर बुलाया जाना चाहिए विधि को बुलाया गया है. <पी> उदाहरण के लिए, आइए authorize पर कॉल करें पोस्ट कंट्रोलर के क्रिएट पर विधि: <पी> इसका परीक्षण करने के लिए, एक संपादक के रूप में लॉग इन करें और create का प्रयास करें एक पोस्ट. ऐसा करने से निम्नलिखित त्रुटि होगी: <पी> 
<पी> हालाँकि यह वही करता है जो हम चाहते हैं, ऐसा त्रुटि पृष्ठ दिखाना उपयोगकर्ता अनुभव के लिए अच्छा नहीं है। अगले भाग में, आप सीखेंगे कि NotAuthorizedError को कैसे बचाया जाए और कुछ अधिक उपयोगकर्ता-अनुकूल परोसें। पंडित के NotAuthorizedError से बचाव
<पी> सबसे पहले, हमें ApplicationController को संपादित करना होगा इस प्रकार: <पी> यहां, हम मूल रूप से पंडित को user_not_authorized का उपयोग करने के लिए कह रहे हैं विधि जब भी NotAuthorizedError उठाया जाता है. यह अनाधिकृत उपयोगकर्ता को एक विशिष्ट पृष्ठ पर पुनर्निर्देशित कर देगा और एक प्रासंगिक फ़्लैश संदेश भी प्रदान करेगा जिसमें बताया जाएगा कि क्या हुआ है: <पी> 
<पी> अब हमारे पास एक सरल प्राधिकरण प्रणाली है जो बहुत सामान्यीकृत अनुमति मामले को संभालने में सक्षम है। <पी> लेकिन क्या होगा यदि हम अधिक सुक्ष्म अनुमतियाँ चाहते हैं? इसके लिए, हमें पंडित के दायरे का उपयोग करने की आवश्यकता है। पंडित का दायरा
<पी> पंडित स्कोप ActiveRecord स्कोप के समान हैं। बाद में, आप विशिष्ट मानदंडों के अनुसार रिकॉर्ड लाने के लिए स्कोप का उपयोग कर सकते हैं। हालाँकि, पंडित के दायरे के साथ, आप अपने द्वारा निर्धारित कुछ नियमों के अनुसार विशिष्ट संसाधनों तक पहुंच का प्रबंधन करते हैं। <पी> मान लीजिए कि हम चाहते हैं कि संपादक उन पोस्ट को देखने और संपादित करने में सक्षम हों जो "ड्राफ्ट" स्थिति में हैं, और साथ ही, लेखकों को उन पोस्ट को बनाने, देखने, संपादित करने, अपडेट करने और हटाने की अनुमति दें जो केवल उनके हैं। <पी> हम पोस्ट नीति को इस तरह संपादित करके प्रारंभ कर सकते हैं: <पी> फिर हम पोस्ट कंट्रोलर में संसाधन तक पहुंच को अधिकृत करेंगे, जैसे: <पी> बेशक, पंडित के साथ दायरा हमारे द्वारा दिखाए गए से कहीं अधिक गहरा हो सकता है, लेकिन हम इस पोस्ट में इसे यहीं छोड़ देंगे। यदि आप चाहें, तो यह देखने के लिए पंडित दस्तावेज़ देखें कि आप अधिक उन्नत तरीके से स्कोप का उपयोग कैसे कर सकते हैं। <पी> अभी के लिए, आइए जानें कि आप रेल्स के मजबूत मापदंडों के साथ लाइब्रेरी का उपयोग कैसे कर सकते हैं। रेल के मजबूत मापदंडों के साथ पंडित का उपयोग करना
<पी> पंडित के प्राधिकरण नियमों को रेल के मजबूत मापदंडों के साथ जोड़कर, आप संसाधन की विशेषताओं तक लॉकडाउन पहुंच प्राप्त कर सकते हैं। मान लीजिए कि आप संपादक चाहते हैं Post के अंश क्षेत्र तक पहुंच रखने वाले एकमात्र व्यक्ति मॉडल. आप इसके बारे में कैसे सोचेंगे? <पी> सबसे पहले, प्रासंगिक नीति में एक उपयुक्त नाम वाला ब्लॉक जोड़ें: <पी> फिर, नियंत्रक में अनुमत पैरामीटर ब्लॉक को संशोधित करें: <पी> इसके साथ, आपने अंश बना लिया है विशेषता केवल संपादकों के लिए उपलब्ध है। <पी> अब हम अन्य प्राधिकरण लाइब्रेरी, CanCanCan को देखने के लिए गियर बदल देंगे। आपके रूबी ऐप के लिए CanCanCan का परिचय
<पी> CanCanCan एक प्राधिकरण लाइब्रेरी है जो यह परिभाषित करने के लिए "क्षमता" वर्ग का उपयोग करती है कि रेल ऐप में किसके पास क्या पहुंच है। वास्तविक पहुंच नियंत्रण एक प्राधिकरण मॉड्यूल और विभिन्न दृश्य सहायकों का उपयोग करके प्राप्त किया जाता है। CanCanCan इंस्टॉल करना
<पी> इंस्टालेशन नीचे दिए गए कमांड को चलाने जितना आसान है: <पी> पंडित की तरह, CanCanCan के साथ, आप सभी एक्सेस नियमों को एक सादे रूबी क्लास ऑब्जेक्ट के भीतर परिभाषित कर सकते हैं जिसे "क्षमता" क्लास कहा जाता है। आइए इसे निम्नलिखित जेनरेटर कमांड के साथ करें: <पी> जो नीचे क्लास ऑब्जेक्ट उत्पन्न करता है: <पी> आइए आगे जानें कि क्षमता वर्ग हमारे उदाहरण रेल ऐप के लिए एक्सेस नियमों को कैसे परिभाषित कर सकता है। कैनकैनकैन क्षमताओं को परिभाषित करना और जांचना
<पी> हम पंडित उदाहरण की तरह ही उपयोगकर्ता भूमिकाओं का उपयोग करेंगे:लेखक और संपादक। एक लेखक अपनी पोस्ट बना सकता है, संपादित कर सकता है, अपडेट कर सकता है, नष्ट कर सकता है और अन्य लेखकों की पोस्ट देख सकता है; एक संपादक अपनी स्वयं की पोस्ट बनाने के अलावा सब कुछ कर सकता है। <पी> CanCanCan का उपयोग करने के लिए, पहले यह परिभाषित करें कि प्रत्येक उपयोगकर्ता या भूमिका इस प्रारूप का पालन करते हुए क्षमता वर्ग में क्या एक्सेस कर सकता है: <पी> उदाहरण के तौर पर: <पी> फिर, नियंत्रक में, जांचें कि क्या किसी विशेष कार्रवाई के लिए एक्सेस नियम मौजूद है - हमारे उदाहरण का उपयोग करके, edit क्रिया: <पी> इसके साथ, यदि हम किसी अन्य लेखक के रूप में संपादन पोस्ट दृश्य पर जाते हैं, तो हमें नीचे दी गई त्रुटि मिलती है: <पी> 
<पी> और जैसा हमने पंडित के साथ किया, आइए इस त्रुटि को बचाएं और उपयोगकर्ता को एक बेहतर त्रुटि पृष्ठ दिखाएं। CanCanCan की "एक्सेस अस्वीकृत" त्रुटियों को संभालना
<पी> जब भी कोई संसाधन अधिकृत नहीं होता है, तो CanCanCan एक CanCan::AccessDenied बढ़ा देगा त्रुटि. इस अपवाद को पकड़ने का सबसे आसान तरीका ApplicationController को संशोधित करना है इस प्रकार: <पी> ऐसा करने से उपयोगकर्ता अनुभव अच्छा होता है। नीचे दिए गए स्क्रीनशॉट में, अनधिकृत उपयोगकर्ता को होम पेज पर रीडायरेक्ट किया जाता है और एक प्रासंगिक फ़्लैश संदेश दिखाया जाता है: <पी> 
<पी> आप उपयोगकर्ता को दिखाए गए त्रुटि संदेश को कस्टमाइज़ भी कर सकते हैं: <पी> यदि आपका ऐप XML को प्रतिक्रिया के रूप में प्रस्तुत करता है, या आप केवल CanCanCan::AccessDenied को संभालने में गहराई से उतरना चाहते हैं अपवाद, CanCanCan के दस्तावेज़ देखें। अभी के लिए, आइए देखें कि हम अधिक मजबूत प्राधिकरण परत बनाने के लिए CanCanCan की विभिन्न क्षमताओं को कैसे जोड़ सकते हैं। एकाधिक CanCanCan क्षमताओं का संयोजन
<पी> आप क्षमता वर्ग में किसी संसाधन के लिए एकाधिक पहुंच नियम परिभाषित कर सकते हैं। उदाहरण के लिए, लेखक और संपादक की भूमिका निभाते हुए, हम यह कर सकते हैं: <पी> सवाल यह है कि आप ऐसा क्यों करना चाहेंगे? <पी> CanCanCan के साथ, आप सभी एक्सेस नियमों को एक क्षमता फ़ाइल में परिभाषित कर सकते हैं। इसके फायदे और नुकसान दोनों हैं। <पी> आपके सभी नियमों को एक ही स्थान पर रखना एक्सेस नियमों को संभालने के लिए बहुत सुविधाजनक है क्योंकि सभी नियम एक ही स्थान पर परिभाषित किए गए हैं। <पी> हालाँकि, यदि आपका ऐप कई उपयोगकर्ता भूमिकाओं से निपटता है या आपके पास कई संसाधन हैं जिन्हें प्राधिकरण की आवश्यकता है, तो क्षमता वर्ग आसानी से संभालने के लिए बहुत बड़ा और जटिल हो सकता है। इसे संभालने का एक तरीका विधि परिभाषाओं का उपयोग करने के लिए क्षमता वर्ग को पुनर्गठित करना है, जैसे: <पी> CanCanCan में और भी बहुत कुछ है जिसे इस लेख में प्रभावी ढंग से शामिल किया जा सकता है। अधिक जानने के लिए विस्तृत CanCanCan दस्तावेज़ देखें। <पी> अंत में, आइए प्रत्येक लाइब्रेरी की विशेषताओं पर संक्षेप में चर्चा करें और कारण बताएं कि आप एक को दूसरे के स्थान पर क्यों चुन सकते हैं। फ़ीचर तुलना:आपके रूबी ऐप के लिए पंडित बनाम CanCanCan
- फ़ाइल संगठन - पंडित के साथ, आप अपने ऐप के प्राधिकरण को कई पॉलिसी फ़ाइलों में आसानी से व्यवस्थित कर सकते हैं। लेकिन CanCanCan के साथ, प्राधिकरण नियम एक क्षमता फ़ाइल में रहेंगे। एकाधिक क्षमता वाली फ़ाइलों के साथ काम करना अभी भी संभव है, लेकिन यह डिफ़ॉल्ट कार्यान्वयन शैली नहीं है।
- परीक्षण - क्योंकि पंडित की बहु-क्षमता कक्षाओं की तुलना में अनुमति कोड अधिकतर एक ही कक्षा में रहेगा, इसलिए पंडित की तुलना में कैनकैनकैन के लिए परीक्षण लिखना आसान हो सकता है।
- मददगार - दोनों लाइब्रेरी दृश्य परत में अनुमतियों की जांच करने के लिए कई दृश्य सहायक प्रदान करती हैं। CanCanCan आपको
can? देता है अपने विचारों में उपयोग करने की विधि, जबकि पंडित आपको policy के साथ अपेक्षाकृत समान कार्यक्षमता प्रदान करता है सहायक.
- एकीकरण तैयार करें - जैसा कि आप लेख में हमारे द्वारा उपयोग किए गए उदाहरणों से देख सकते हैं, दोनों लाइब्रेरी डेविस के साथ बहुत अच्छी तरह से एकीकृत हैं।
समापन
<पी> इस लेख में, हमने रूबी और रेल्स पारिस्थितिकी तंत्र में दो सबसे लोकप्रिय प्राधिकरण रत्नों को देखा:पंडित और कैनकैनकैन। <पी> दोनों लाइब्रेरी आपके रेल ऐप में अनुमतियों के प्रबंधन के लिए सुविधाओं का एक समृद्ध सेट प्रदान करती हैं। इस वजह से, आपको यह बताना लगभग असंभव है कि कौन सा रत्न चुनना है - दोनों सबसे जटिल अनुमति सेटअप को भी प्रबंधित कर सकते हैं। <पी> हम आपको अपने ऐप में पंडित और कैनकैनकैन को आज़माने के लिए प्रोत्साहित करते हैं और देखें कि कौन सा आपकी आवश्यकताओं के लिए सबसे उपयुक्त है। <पी> हैप्पी कोडिंग! <पी> पी.एस. यदि आप प्रेस से हटते ही रूबी मैजिक पोस्ट पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और एक भी पोस्ट न चूकें!
