रूबी ऑथराइज़ेशन मास्टर करें: Pundit बनाम CanCanCan

आज, कई वेब एप्लिकेशन में पेज होंगे जो सार्वजनिक रूप से उपलब्ध हैं - जैसे होमपेज - और अधिक सुरक्षित जहां यूजर को एक्सेस प्राप्त करने के लिए लॉग इन करना होगा। यूजर रजिस्ट्रेशन, लॉग इन करने और यूजर सेशन स्थिति को ट्रैक करने की प्रक्रिया को "ऑथेंटिकेशन" कहा जाता है।

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

इस पोस्ट में, हम अब तक रूबी में दो सबसे लोकप्रिय ऑथराइज़ेशन लाइब्रेरी का पता लगाएंगे: Pundit और CanCanCan।

आइए गोता लगाएं!

सेटअप और पूर्वापेक्षाएँ

इस लेख में, हम यूजर्स और पोस्ट्स की विशेषता वाले एक सिंपल रेल्स 7 ऐप का उपयोग करेंगे। यूजर्स को "एडिटर" या "राइटर" भूमिका दी जाएगी। ऐसा परिदृश्य ऑथराइज़ेशन कैसे काम करता है यह दिखाने के लिए एकदम सही है।

हमारे उदाहरण ऐप के कोड रेपो देखें:

• Pundit के साथ
• CanCanCan के साथ

भले ही यह लेख ऑथराइज़ेशन पर केंद्रित है, साथी विषय ऑथेंटिकेशन को नजरअंदाज नहीं किया जा सकता।

हम ऑथेंटिकेशन सेट अप करने के विवरण में नहीं जाएंगे क्योंकि यह इस पोस्ट के दायरे से बाहर है। आप Devise जेम डॉक्यूमेंटेशन में इंस्टॉलेशन निर्देशों का पालन कर सकते हैं (हम अपने ऑथराइज़ेशन जेम्स के साथ Devise को पेयर करेंगे)।

एक और बात - चाहे आप Pundit या CanCanCan से निपटें, अपने ऐप के यूजर रोल्स को परिभाषित करने का वास्तविक काम तब ऑटोमैटिकली नहीं होता जब आप ऑथराइज़ेशन जेम्स में से किसी एक को इंस्टॉल करते हैं। आपको इसे मैन्युअली सेट अप करना होगा।

आइए ऐसा करें।

यूजर रोल्स को परिभाषित करना

मान लें कि आपने पहले ही Devise जेम इंस्टॉल कर लिया है और एक यूजर मॉडल सेट अप कर लिया है। अगला कदम यह तय करना है कि ऐप के यूजर्स की क्या भूमिकाएं होंगी। हमारे मामले में, हम निम्नलिखित भूमिकाओं को निर्धारित करेंगे:

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

यूजर की भूमिका स्टोर करने के लिए एक कॉलम जोड़ें (यूजर टेबल को संशोधित करने के लिए माइग्रेशन का उपयोग करके):

फिर माइग्रेशन चलाएं:

और फिर यूजर मॉडल को संशोधित करें ताकि हमने अभी परिभाषित की गई भूमिकाओं को शामिल किया जा सके:

जब हम इस पर हैं, तो आइए आगे बढ़ें और Post मॉडल को title और body एट्रिब्यूट्स के साथ सेट अप करें, साथ ही पोस्ट लिखने वाले यूजर का संदर्भ:

हम Post मॉडल में विदेशी कुंजी user_id जोड़ते हैं ताकि बनाए गए प्रत्येक पोस्ट को एक विशेष यूजर के साथ जोड़ा जा सके। चूंकि हमने पहले ही Devise का उपयोग करके यूजर ऑथेंटिकेशन सेट अप कर लिया है, हम बस Posts कंट्रोलर के create मेथड को संशोधित कर सकते हैं ताकि user_id को वर्तमान में लॉग-इन यूजर पर स्वचालित रूप से सेट किया जा सके:

हम यूजर मॉडल को यह सुनिश्चित करने के लिए भी संशोधित कर सकते हैं कि यह Post मॉडल के साथ जुड़ा हुआ है:

अंत में, आइए डेटाबेस को कुछ यूजर्स के साथ बीज दें, प्रत्येक की एक अलग भूमिका:

फिर डेटाबेस को बीज दें:

अब तक, हमारे ऐप में अब है:

• Devise का उपयोग करके सेट अप ऑथेंटिकेशन।
• "राइटर" और "एडिटर" की दो परिभाषित यूजर भूमिकाएं।
• एक Post मॉडल।

उसके साथ, हमारे पास अब Pundit के साथ ठीक से काम करने के लिए आवश्यक सब कुछ है।

Pundit के साथ अपने रूबी ऐप में ऑथराइज़ेशन

Pundit एक ऑथराइज़ेशन लाइब्रेरी है जो ऑब्जेक्ट-ओरिएंटेड आर्किटेक्चर और प्लेन रूबी क्लासेस के आसपास बनाई गई है। यह आपको एक ठोस ऑथराइज़ेशन लेयर बनाने के लिए टूल देता है जो आपके ऐप के साथ स्केल कर सकता है।

अपने रूबी ऐप में Pundit इंस्टॉल करना

अपने ऐप के Gemfile में जेम जोड़ें:

फिर टर्मिनल में, कमांड चलाएं:

वैकल्पिक रूप से, निम्न कमांड चलाएं:

चूंकि ऑथराइज़ेशन ज्यादातर कंट्रोलर रिसोर्सेज तक एक्सेस देने या अस्वीकार करने से संबंधित है, अगला कदम एप्लिकेशन कंट्रोलर में Pundit के ऑथराइज़ेशन मॉड्यूल को जोड़ना है:

और अंत में, एक बेस पॉलिसी क्लास जनरेट करें जिससे अन्य सभी पॉलिसी इनहेरिट करेंगे:

जो आपको निम्न बेस पॉलिसी क्लास देता है:

उसके साथ, Pundit अब ठीक से सेट अप है और जाने के लिए तैयार है। इसके अलावा, हमारे पास ऑथेंटिकेशन और यूजर रोल्स सेट अप हैं।

अब, आइए पॉलिसीज़ का उपयोग करके नियमों को लागू करें जो परिभाषित करते हैं कि प्रत्येक यूजर भूमिका Post रिसोर्स तक कैसे पहुंचेगी।

Pundit पॉलिसीज़ कॉन्फिगर करना

Pundit की भाषा में, एक "पॉलिसी" एक प्लेन रूबी क्लास है जहां आप परिभाषित करते हैं कि एक यूजर भूमिका विभिन्न रिसोर्सेज के साथ कैसे इंटरैक्ट करती है।

ये पॉलिसीज़ कुछ उल्लेखनीय विशेषताओं के साथ आती हैं:

• प्रत्येक पॉलिसी का नाम एक मौजूदा मॉडल के नाम पर रखा जाता है, जिसे "Policy" शब्द से सफ़िक्स किया जाता है। उदाहरण के लिए, Post मॉडल को कैसे एक्सेस किया जाता है यह परिभाषित करने वाली पॉलिसी को PostPolicy कहा जाता है।
• एक attr_reader: यह दो आर्गुमेंट लेता है - पहला एक user है, विशेष रूप से वर्तमान में लॉग-इन यूजर — current_user — और दूसरा आर्गुमेंट वह मॉडल है जिसके लिए आप ऑथराइज़ेशन नियम परिभाषित करना चाहते हैं, हमारे मामले में, post।
• क्वेरी मेथड्स जो उस रिसोर्स के कंट्रोलर मेथड्स पर मैप होंगे जिस पर ऑथराइज़ेशन नियम सेट अप हैं। संगठनात्मक उद्देश्यों के लिए, सभी पॉलिसीज़ को app/policies फोल्डर के तहत रखना सबसे अच्छा है।

चूंकि हम जानते हैं कि हमारे ऐप में विभिन्न यूजर भूमिकाओं के लिए किन एक्सेस नियमों को परिभाषित करने की आवश्यकता है, आइए राइटर भूमिका से शुरू करें।

एक भूमिका के लिए Pundit पॉलिसी परिभाषित करना

आइए देखें कि यह कैसे किया जा सकता है राइटर भूमिका का उपयोग करके। शुरू करने के लिए, हम Post रिसोर्स के लिए राइटर भूमिका की एक्सेस को इस रूप में रेखांकित कर सकते हैं:

• बनाएं अपने स्वयं के पोस्ट
• संपादित और अपडेट करें अपने स्वयं के पोस्ट
• देखें (या पढ़ें) अपने स्वयं के पोस्ट साथ ही अन्य यूजर के पोस्ट
• हटाएं अपने स्वयं के पोस्ट

इस बात को ध्यान में रखते हुए, पोस्ट कैसे एक्सेस किए जाते हैं इसे नियंत्रित करने के लिए एक नई पॉलिसी जनरेट करें:

यह हमें निम्न जेनेरिक पॉलिसी क्लास देता है जो पहले जनरेट की गई बेस पॉलिसी से इनहेरिट करती है:

अब राइटर भूमिका के लिए तदनुसार एक्सेस नियम जोड़ें (ये बेस पॉलिसी क्लास से इनहेरिट किए गए किसी भी नियम को ओवरराइड भी करते हैं):

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

अभी के लिए, आइए देखें कि हम इस पॉलिसी का उपयोग कैसे कर सकते हैं।

Pundit में पॉलिसी का उपयोग करना

पॉलिसी का उपयोग करने के लिए, कंट्रोलर के मेथड पर Pundit के authorize मेथड को कॉल करें जहां आप एक्सेस नियमों की जांच करना चाहते हैं। आप संबंधित पॉलिसी क्लास को इंस्टेंटिएट करते हैं और, अधिक विशेष रूप से, वह एक्शन जिसे उस आधार पर कॉल किया जाना चाहिए जहां authorize मेथड को कॉल किया गया है।

उदाहरण के लिए, आइए पोस्ट कंट्रोलर के create मेथड पर authorize कॉल करें:

इसे टेस्ट करने के लिए, एडिटर के रूप में लॉग इन करें और create पोस्ट करने का प्रयास करें। ऐसा करने का परिणाम निम्न एरर होगा:

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

Pundit के NotAuthorizedError से रेस्क्यू करना

सबसे पहले, हमें ApplicationController को निम्नानुसार संपादित करने की आवश्यकता होगी:

यहां, हम मूल रूप से Pundit को बता रहे हैं कि जब भी NotAuthorizedError उठाया जाता है तो user_not_authorized मेथड का उपयोग करें। यह अनधिकृत यूजर को एक विशिष्ट पेज पर रीडायरेक्ट करेगा और जो हुआ उसकी व्याख्या करने वाला एक प्रासंगिक फ्लैश मैसेज भी प्रदान करेगा:

अब हमारे पास एक सिंपल ऑथराइज़ेशन सिस्टम है जो बहुत सामान्यीकृत परमिशन केस को संभालने में सक्षम है।

लेकिन क्या होगा यदि हम अधिक फाइन-ग्रेन्ड परमिशन चाहते हैं? इसके लिए, हमें Pundit के स्कोप का उपयोग करने की आवश्यकता है।

Pundit के स्कोप

Pundit स्कोप ActiveRecord स्कोप के समान हैं। बाद में, आप विशिष्ट मानदंडों के अनुसार रिकॉर्ड लाने के लिए स्कोप का उपयोग कर सकते हैं। हालांकि, Pundit के स्कोप के साथ, आप कुछ नियमों के अनुसार विशिष्ट रिसोर्सेज तक एक्सेस का प्रबंधन करते हैं जो आप सेट करते हैं।

मान लें कि हम एडिटर्स को "ड्राफ्ट" स्थिति में पोस्ट देखने और संपादित करने में सक्षम बनाना चाहते हैं, और साथ ही, राइटर्स को केवल उनके अपने पोस्ट बनाने, देखने, संपादित करने, अपडेट करने और हटाने की अनुमति देना चाहते हैं।

हम पोस्ट पॉलिसी को इस तरह संपादित करके शुरू कर सकते हैं:

फिर हम पोस्ट कंट्रोलर में रिसोर्स तक एक्सेस को अधिकृत करेंगे, जैसे:

बेशक, Pundit के साथ स्कोपिंग इससे कहीं अधिक गहरी जा सकती है जितना हमने दिखाया है, लेकिन हम इसे इस पोस्ट में यहीं छोड़ देंगे। यदि आप चाहते हैं, तो Pundit डॉक्यूमेंटेशन देखें कि आप स्कोप का अधिक उन्नत तरीके से उपयोग कैसे कर सकते हैं।

अब, आइए देखें कि आप रेल्स के स्ट्रांग पैरामीटर्स के साथ लाइब्रेरी का उपयोग कैसे कर सकते हैं।

रेल्स के स्ट्रांग पैरामीटर्स के साथ Pundit का उपयोग करना

Pundit के ऑथराइज़ेशन नियमों को रेल्स के स्ट्रांग पैरामीटर्स के साथ जोड़कर, आप एक रिसोर्स के एट्रिब्यूट्स तक लॉकडाउन एक्सेस प्राप्त कर सकते हैं। मान लें कि आप चाहते हैं कि एडिटर्स केवल Post मॉडल के एक एक्सर्प्ट फील्ड तक पहुंच वाले हों। आप इसके बारे में कैसे जाएंगे?

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

फिर, कंट्रोलर में परमिटेड पैरामीटर्स ब्लॉक को संशोधित करें:

उसके साथ, आपने एक्सर्प्ट एट्रिब्यूट को केवल एडिटर्स के लिए उपलब्ध करा दिया है।

अब हम दूसरे ऑथराइज़ेशन लाइब्रेरी, CanCanCan को देखने के लिए गियर बदलेंगे।

अपने रूबी ऐप के लिए CanCanCan का परिचय

CanCanCan एक ऑथराइज़ेशन लाइब्रेरी है जो रेल्स ऐप में किसके पास क्या एक्सेस है यह परिभाषित करने के लिए एक "एबिलिटी" क्लास का उपयोग करती है। वास्तविक एक्सेस कंट्रोल एक ऑथराइज़ेशन मॉड्यूल और विभिन्न व्यू हेल्पर्स का उपयोग करके प्राप्त किया जाता है।

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

इंस्टॉलेशन नीचे दी गई कमांड चलाने जितना आसान है:

Pundit की तरह, CanCanCan के साथ, आप एक प्लेन रूबी क्लास ऑब्जेक्ट के भीतर सभी एक्सेस नियमों को परिभाषित कर सकते हैं जिसे "एबिलिटी" क्लास कहा जाता है। आइए अगले जनरेटर कमांड के साथ ऐसा करें:

जो नीचे दी गई क्लास ऑब्जेक्ट जनरेट करता है:

आइए आगे जानें कि एबिलिटी क्लास हमारे उदाहरण रेल्स ऐप के लिए एक्सेस नियमों को कैसे परिभाषित कर सकती है।

CanCanCan एबिलिटी को परिभाषित करना और जांचना

हम Pundit उदाहरण के समान यूजर भूमिकाओं का उपयोग करेंगे: राइटर्स और एडिटर्स। एक राइटर अपने स्वयं के पोस्ट बना, संपादित, अपडेट, नष्ट कर सकता है, और अन्य राइटर्स के पोस्ट देख सकता है; एक एडिटर अपने स्वयं के पोस्ट बनाने के अलावा सब कुछ कर सकता है।

CanCanCan का उपयोग करने के लिए, पहले एबिलिटी क्लास में परिभाषित करें कि प्रत्येक यूजर या भूमिका क्या एक्सेस कर सकती है, इस प्रारूप का पालन करते हुए:

एक उदाहरण के रूप में:

फिर, कंट्रोलर में, जांचें कि क्या किसी विशेष एक्शन के लिए एक एक्सेस नियम मौजूद है — हमारे उदाहरण का उपयोग करते हुए, edit एक्शन:

इसे लागू करने के साथ, यदि हम किसी अन्य राइटर के रूप में एडिट पोस्ट व्यू पर जाते हैं, तो हमें नीचे दी गई एरर मिलती है:

और जैसे हमने Pundit के साथ किया था, आइए इस एरर को रेस्क्यू करें और यूजर को एक बेहतर एरर पेज दिखाएं।

CanCanCan के "एक्सेस डिनाइड" एरर को संभालना

जब भी कोई रिसोर्स अधिकृत नहीं होता है, CanCanCan एक CanCan::AccessDenied एरर उठाएगा। इस अपवाद को पकड़ने का सबसे आसान तरीका ApplicationController को निम्नानुसार संशोधित करना है:

यह एक अच्छा यूजर एक्सपीरियंस बनाता है। नीचे स्क्रीनशॉट में, अनधिकृत यूजर को होम पेज पर रीडायरेक्ट किया जाता है और एक प्रासंगिक फ्लैश मैसेज दिखाया जाता है:

आप यूजर को दिखाए जाने वाले एरर मैसेज को कस्टमाइज़ भी कर सकते हैं:

यदि आपका ऐप XML को प्रतिक्रिया के रूप में सर्व करता है, या आप बस CanCanCan::AccessDenied अपवाद को संभालने में गहराई से जाना चाहते हैं, तो CanCanCan के डॉक्यूमेंटेशन देखें। अभी के लिए, आइए देखें कि हम CanCanCan की विभिन्न एबिलिटी को कैसे जोड़ सकते हैं एक अधिक मजबूत ऑथराइज़ेशन लेयर बनाने के लिए।

एकाधिक CanCanCan एबिलिटी को जोड़ना

आप एबिलिटी क्लास में एक रिसोर्स के लिए एकाधिक एक्सेस नियम परिभाषित कर सकते हैं। राइटर और एडिटर भूमिकाओं को लेते हुए, उदाहरण के लिए, हम यह कर सकते हैं:

सवाल यह है, आप ऐसा क्यों करना चाहेंगे?

CanCanCan के साथ, आप सभी एक्सेस नियमों को एक एबिलिटी फाइल में परिभाषित कर सकते हैं। इसके फायदे और नुकसान दोनों हैं।

एक ही स्थान पर अपने सभी नियमों का होना एक्सेस नियमों को संभालने के लिए बहुत सुविधाजनक है क्योंकि सभी नियम एक ही स्थान पर परिभाषित हैं।

हालांकि, यदि आपका ऐप कई यूजर भूमिकाओं से निपटता है या आपके पास कई रिसोर्स हैं जिनके लिए ऑथराइज़ेशन की आवश्यकता है, तो एबिलिटी क्लास आसानी से बहुत बड़ी और जटिल हो सकती है। इसे संभालने का एक तरीका एबिलिटी क्लास को मेथड डेफिनिशन का उपयोग करने के लिए पुनर्गठित करना है, जैसे:

CanCanCan के बारे में इससे कहीं अधिक है जिसे इस लेख में प्रभावी ढंग से कवर किया जा सकता है। अधिक जानने के लिए विस्तृत CanCanCan डॉक्यूमेंटेशन देखें।

समाप्त करने के लिए, आइए प्रत्येक लाइब्रेरी की विशेषताओं को संक्षेप में स्पर्श करें और कारण दें कि आप एक को दूसरे पर क्यों चुन सकते हैं।

फीचर तुलना: आपके रूबी ऐप के लिए Pundit बनाम CanCanCan

• फाइल संगठन - Pundit के साथ, आप अपने ऐप के ऑथराइज़ेशन को कई पॉलिसी फाइलों में आसानी से व्यवस्थित कर सकते हैं। लेकिन CanCanCan के साथ, ऑथराइज़ेशन नियम एक एबिलिटी फाइल में रहेंगे। कई एबिलिटी फाइलों के साथ काम करना अभी भी संभव है, लेकिन यह डिफ़ॉल्ट कार्यान्वयन शैली नहीं है।
• टेस्ट - क्योंकि परमिशन कोड ज्यादातर Pundit के कई एबिलिटी क्लास की तुलना में एक ही क्लास के भीतर रहेगा, CanCanCan के लिए टेस्ट लिखना Pundit की तुलना में आसान हो सकता है।
• हेल्पर्स - दोनों लाइब्रेरी व्यू लेयर में परमिशन की जांच के लिए कई व्यू हेल्पर्स प्रदान करती हैं। CanCanCan आपको अपने व्यूज में उपयोग करने के लिए can? मेथड देता है, जबकि Pundit आपको policy हेल्पर के साथ अपेक्षाकृत समान कार्यक्षमता देता है।
• Devise इंटीग्रेशन - जैसा कि आप इस लेख में उपयोग किए गए उदाहरणों से देख सकते हैं, दोनों लाइब्रेरी Devise के साथ बहुत अच्छी तरह से इंटीग्रेट होती हैं।

समापन

इस लेख में, हमने रूबी और रेल्स इकोसिस्टम में दो सबसे लोकप्रिय ऑथराइज़ेशन जेम्स को देखा: Pundit और CanCanCan।

दोनों लाइब्रेरी आपके रेल्स ऐप में परमिशन प्रबंधित करने के लिए सुविधाओं का एक समृद्ध सेट प्रदान करती हैं। इस वजह से, यह बताना लगभग असंभव है कि कौन सा जेम चुनना है - दोनों सबसे जटिल परमिशन सेटअप को भी प्रबंधित कर सकते हैं।

हम आपको अपने ऐप में Pundit और CanCanCan दोनों को आज़माने और यह देखने के लिए प्रोत्साहित करते हैं कि कौन सा आपकी आवश्यकताओं के लिए सबसे उपयुक्त है।

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

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