रूबी ऑन रेल्स में एक्शन पॉलिसी में महारत हासिल करना:प्राधिकरण सुरक्षित करने के लिए एक व्यावहारिक मार्गदर्शिका
<पी> अपने ऐप को सुरक्षित रखने के लिए, आपको यह नियंत्रित करना होगा कि इसे कौन और कौन एक्सेस कर सकता है। अभिगम नियंत्रण को प्रमाणीकरण में वर्गीकृत किया जा सकता है - "किसे" अनुमति देनी है - और प्राधिकरण - "क्या" वे पहुंच सकते हैं। <पी> प्रमाणीकरण एक और दिन का विषय है, लेकिन जब उपयोगकर्ता प्राधिकरण की बात आती है, तो आपके पास इसके बारे में जाने के आम तौर पर दो तरीके होते हैं:भूमिका-आधारित या संसाधन-आधारित रणनीति का उपयोग करना। <पी> इस दो-भाग की श्रृंखला में, हम रूबी ऑन रेल्स ब्लॉग एप्लिकेशन के लिए एक्शन पॉलिसी रत्न का उपयोग करने पर गहराई से विचार करेंगे। <पी> इस भाग में, हम कार्य नीति की मूल बातें कवर करेंगे। <पी> आइए शुरू करें! आवश्यकताएँ
- रूबी (हम संस्करण 3.2.2 का उपयोग कर रहे हैं)
- रेल (संस्करण 7.0.7 का उपयोग करके)
- रूबी का उपयोग करने का कुछ अनुभव
<पी> आइए पहले संसाधन-आधारित प्राधिकरण को परिभाषित करके इसमें शामिल हों। संसाधन-आधारित प्राधिकरण क्या है?
<पी> जहाँ भूमिका-आधारित प्राधिकरण पूर्वनिर्धारित उपयोगकर्ता भूमिकाओं के अनुसार उपयोगकर्ता अनुमतियाँ निर्धारित करने पर ध्यान केंद्रित करता है, वहीं संसाधन-आधारित प्राधिकरण किसी एप्लिकेशन के भीतर वास्तविक संसाधनों पर नियम निर्धारित करके पहुंच को लागू करता है। प्रत्येक संसाधन एक नीति से जुड़ा होता है जो स्पष्ट रूप से परिभाषित करता है कि उपयोगकर्ता उस संसाधन पर क्या कर सकता है। <पी> भले ही यह लेख संसाधन-आधारित प्राधिकरण पर केंद्रित है, दो प्राधिकरण रणनीतियों के बीच अंतर जानने का मतलब है कि आप यह जानने के लिए बेहतर ढंग से सुसज्जित हैं कि प्रत्येक क्या कर सकता है। भूमिका-आधारित प्राधिकरण का उपयोग कब करें
<पी> आपको इसके लिए भूमिका-आधारित प्राधिकरण का उपयोग करना चाहिए: - सरल अनुप्रयोग - यदि आप एक सीधी अनुमति प्रणाली और कम उपयोगकर्ता भूमिकाओं वाले ऐप पर काम कर रहे हैं, तो भूमिका-आधारित प्राधिकरण रणनीति आपके लिए काम कर सकती है।
- अच्छी तरह से परिभाषित उपयोगकर्ता समूह - यदि आपके ऐप में "एडमिन", "संपादक", "लेखक" आदि जैसे अच्छी तरह से परिभाषित उपयोगकर्ता समूह हैं, तो भूमिका-आधारित प्राधिकरण का उपयोग करें क्योंकि यह उपयोगकर्ता भूमिका स्तर पर पहुंच नियंत्रण को संभालता है।
संसाधन-आधारित प्राधिकरण का उपयोग कब करें
<पी> संसाधन-आधारित प्राधिकरण इसके लिए बहुत अच्छा है: - गतिशील या जटिल अभिगम नियंत्रण - जब आपके एप्लिकेशन की प्राधिकरण आवश्यकताएँ बार-बार विकसित होती हैं या गतिशील स्थितियों द्वारा निर्धारित होती हैं, तो संसाधन-आधारित प्राधिकरण प्रणाली बेहतर विकल्प बनाती है।
- सूक्ष्म नियंत्रण - तब उपयोगी जब आपको कई शर्तों के आधार पर संसाधनों तक पहुंच की अनुमति देने या अस्वीकार करने की आवश्यकता होती है (उदाहरण के लिए, एक रेल हेल्पडेस्क ऐप जहां उपयोगकर्ता गतिशील श्रेणियों की सूची के आधार पर समर्थन टिकट जमा करते हैं)। यह मानते हुए कि सहायक कर्मचारियों को श्रेणी के आधार पर टिकट आवंटित किए जाते हैं, यह एक ऐसा परिदृश्य है जहां संसाधन-आधारित प्राधिकरण वास्तव में चमकेगा।
- वस्तु-उन्मुख नियंत्रण - क्योंकि संसाधन-आधारित प्राधिकरण ऑब्जेक्ट स्तर पर होता है, जब आप संसाधन-आधारित प्राधिकरण तकनीकों का उपयोग करते हैं तो जटिल ऑब्जेक्ट-उन्मुख नियमों को परिभाषित करना आसान होता है।
<पी> जैसा कि कहा गया है, आप भूमिका-आधारित और संसाधन-आधारित प्राधिकरण के बीच चयन करते हैं या नहीं, यह आपके एप्लिकेशन की विशिष्ट विशेषताओं पर निर्भर करेगा। <पी> आइए अब अपना ध्यान एक्शन पॉलिसी मणि पर केंद्रित करें। रूबी और रेल्स के लिए एक्शन पॉलिसी जेम
<पी> एक्शन पॉलिसी रूबी और रेल्स ऐप्स के लिए एक लचीला, विस्तार योग्य और निष्पादन योग्य प्राधिकरण ढांचा है। यह बॉक्स से बाहर कई कैशिंग रणनीतियों का उपयोग करता है, जिससे यह बहुत तेज़ हो जाता है, खासकर यदि आपके प्राधिकरण नियमों के लिए डेटाबेस क्वेरी की आवश्यकता होती है। <पी> एक अन्य विशेषता जो इस रत्न को संसाधन-आधारित नियमों के निर्माण के लिए आदर्श बनाती है, वह है इसकी अनुकूलित करने की क्षमता। यह कई रूबी कक्षाएं और मॉड्यूल प्रदान करता है जिन्हें कई तरीकों से जोड़ा जा सकता है। आप अपने ऐप में कहीं भी, रेल्स कंट्रोलर से परे बहुत अच्छे एक्सेस कंट्रोल नियम सेट कर सकते हैं। <पी> अधिक जानने के लिए एक्शन पॉलिसी प्रोजेक्ट होमपेज देखें। <पी> आइए अब उस रेल ऐप पर नजर डालें जिसे हम आज बना रहे हैं। रेल ऐप बनाएं
<पी> आगे बढ़ते हुए, हम एक रेल 7 ब्लॉग एप्लिकेशन का संदर्भ देंगे जहां उपयोगकर्ता (सीआरयूडी) पोस्ट बना सकते हैं, पढ़ सकते हैं, अपडेट कर सकते हैं और हटा सकते हैं। <पी> हम Post के लिए उत्तरोत्तर एक कार्य नीति परिभाषित करेंगे मॉडल जो संसाधन-आधारित पहुंच नियंत्रण प्रदान करता है। आप सीखेंगे कि इस एक्सेस कंट्रोल रणनीति को कार्यान्वित करने के लिए एक्शन पॉलिसी का उपयोग कैसे करें। <पी> आगे बढ़ें और एक नया रेल एप्लिकेशन जनरेट करें: <पी> नोट: हम अपने उदाहरण ऐप के लिए पिको सीएसएस शैलियों का उपयोग करेंगे, लेकिन आप जो चाहें उसका उपयोग कर सकते हैं। <पी> फिर जल्दी से एक Post तैयार करें वह संसाधन जिसका उपयोग हम शेष ट्यूटोरियल में करेंगे: <पी> अब rails db:migrate के साथ माइग्रेशन चलाएँ . उपयोगकर्ता प्रमाणीकरण सेट करना
<पी> यद्यपि यह लेख उपयोगकर्ता प्राधिकरण के बारे में है, इसमें कुछ महत्वपूर्ण बात है जिसे हमें कवर करने की आवश्यकता है:उपयोगकर्ता प्रमाणीकरण। इसके बिना, कोई भी प्राधिकरण नीति जिसे हम बाद में परिभाषित करने का प्रयास करेंगे, बेकार हो जाएगी। लेकिन स्क्रैच से प्रमाणीकरण लिखने की कोई आवश्यकता नहीं है। आइए डेविस का उपयोग करें। डिवाइस स्थापित करना
<पी> अपने जेमफ़ाइल में डेविस रत्न जोड़कर शुरुआत करें: <पी> फिर इसे इंस्टॉल करें और एक User जेनरेट करें मॉडल: <पी> साथ ही, config.action_mailer.default_url_options = { host: 'localhost', port: 3000 } जोड़ना याद रखें ऐप के विकास कॉन्फ़िगरेशन के लिए। <पी> आगे, आइए Post के लिए विभिन्न उपयोगकर्ता पहुंच परिदृश्यों का परीक्षण करने के लिए कुछ बुनियादी उपयोगकर्ता भूमिकाएं लागू करें संसाधन. बुनियादी उपयोगकर्ता भूमिकाओं को परिभाषित करना
<पी> सबसे पहले, role जोड़ें उपयोगकर्ता तालिका में कॉलम। माइग्रेशन उत्पन्न करने के लिए यह कमांड चलाएँ: <पी> नोट: हम भूमिका के लिए पूर्णांक डेटा प्रकार का उपयोग करते हैं, इसलिए हम enum का उपयोग कर सकते हैं — भूमिकाओं को लागू करने का एक त्वरित और आसान तरीका। <पी> अब rails db:migrate के साथ माइग्रेशन चलाएँ , फिर User खोलें इसे मॉडल करें और संपादित करें: <पी> यह हो जाने के बाद, आइए अपना ध्यान एक्शन पॉलिसी स्थापित करने पर केंद्रित करें। रूबी और रेल्स के लिए एक्शन पॉलिसी सेट करना
<पी> ऐप का Gemfile खोलें और नीचे पंक्ति जोड़ें: <पी> फिर कमांड bundle install चलाएँ एक्शन पॉलिसी स्थापित करने के लिए। <पी> चलाकर संस्थापन को अंतिम रूप दें: <पी> इससे हमें एक आधार मिलना चाहिए - ApplicationPolicy app/policies के अंतर्गत कक्षा : कार्य नीति का मूल उपयोग
<पी> एक्शन पॉलिसी का मूल आधार एक policy है कक्षा, ApplicationPolicy , जहां आप वैश्विक कॉन्फ़िगरेशन को परिभाषित कर सकते हैं जिससे सभी नीतियां विरासत में मिल सकती हैं। एक अच्छी अनुशंसा यह है कि सभी पॉलिसियों को app/policies के अंतर्गत रखा जाए , और आपके ऐप में संसाधनों के अनुसार नीतियों को अलग करना। उदाहरण के लिए, यदि आपके पास Post है संसाधन, संबंधित नीति PostPolicy होनी चाहिए , CommentPolicy Comment के साथ होगा संसाधन, इत्यादि। <पी> एक्शन पॉलिसी के साथ काम करते समय एक और बात पर विचार करना चाहिए:नीति वर्गों में सार्वजनिक तरीकों के भीतर नियम परिभाषाएँ होनी चाहिए। निजी पद्धति का उपयोग करने से त्रुटि उत्पन्न होगी। <पी> आगे बढ़ते हुए, आइए इस जानकारी का उपयोग PostPolicy बनाने के लिए करें जहां हम उत्तरोत्तर उपयोगकर्ता पहुंच के विभिन्न स्तरों का निर्माण करेंगे। हमारी पहली नीति बनाना
<पी> post_policy.rb नाम से एक नई फ़ाइल बनाएं app/policies के अंतर्गत : <पी> यहां, हम Post पर एक सरल नियम परिभाषित करते हैं संसाधन यह घोषणा कर रहा है कि कोई भी Post तक पहुंच सकता है . पोस्ट को उपयोगकर्ताओं से जोड़ना
<पी> इस नई पोस्ट नीति के साथ काम करने के लिए, हमें Post को संशोधित करने की आवश्यकता है संसाधन हमने पहले तैयार किया था ताकि यह निर्माण पर लॉग-इन उपयोगकर्ता के साथ जुड़ा हो (user_id जोड़कर) पोस्ट तालिका में कॉलम): <पी> फिर rails db:migrate के साथ माइग्रेशन चलाएँ . <पी> इसके बाद, हमें इस बदलाव को ध्यान में रखते हुए पोस्ट कंट्रोलर को संशोधित करना होगा। सबसे पहले, आइए user_id जोड़ें अनुमत post_params के लिए : <पी> फिर create को संशोधित करें क्रिया: <पी> इसके बाद, आइए PostsController को सुरक्षित करें . नियंत्रकों में प्राधिकरण लागू करना
<पी> हमें PostsController को संशोधित करने की आवश्यकता है केवल लॉग-इन उपयोगकर्ताओं तक पहुंच की अनुमति देने के लिए कॉलबैक के साथ: <पी> इसके बाद, आइए कुछ बुनियादी उपयोगकर्ता पहुंच नियंत्रण जोड़ने के लिए नई पोस्ट नीति का उपयोग करें: <पी> यहां, हम पोस्ट कंट्रोलर के update पर एक एक्सेस नियम परिभाषित करते हैं और destroy कार्रवाई. हम निर्दिष्ट करते हैं कि किसी पोस्ट का लेखक (या "लेखक" भूमिका वाला उपयोगकर्ता) किसी पोस्ट को अपडेट कर सकता है, लेकिन केवल पोस्ट का लेखक ही किसी पोस्ट को हटा सकता है। <पी> त्वरित टिप: कार्रवाई नीति current_user का संदर्भ दे सकती है डेविस द्वारा प्रदान किया गया और इसे user पर असाइन करें नीति के अंतर्गत. <पी> इसके बाद, हमें पोस्ट कंट्रोलर में एक्सेस नियम का उपयोग इस प्रकार करना होगा: <पी> पोस्ट कंट्रोलर पर एक्सेस नियम लागू होने के साथ, हमारी अगली कार्रवाई यह सुनिश्चित करना है कि व्यू सुरक्षित हैं। प्राधिकरण के साथ दृश्यों की सुरक्षा
<पी> नीचे दिए गए स्क्रीनशॉट में, एक उपयोगकर्ता जिसके पास ईमेल <user2@example.com> है और "पाठक" भूमिका लॉग इन है। जैसा कि आप देख सकते हैं, यह उपयोगकर्ता <user@example.com> द्वारा बनाई गई पोस्ट देख सकता है , और उनके पास इस पोस्ट के संपादन और डिलीट लिंक तक भी पहुंच है। यह आदर्श नहीं है - संपादित करें और हटाएं लिंक केवल पोस्ट के लेखक के लिए उपलब्ध होना चाहिए। <पी> 
<पी> हमारा पहला काम उन उपयोगकर्ताओं के लिए इन लिंक तक पहुंच को हटाना होगा जो किसी पोस्ट के लेखक नहीं हैं। चूँकि हमने पहले ही इस एक्सेस नियम को परिभाषित कर दिया है, हमें इसे केवल show पर लागू करने की आवश्यकता है एक्शन पॉलिसी के निफ्टी allowed_to? का उपयोग करके देखें विधि: <पी> इस नियम के लागू होने से, अब हम पोस्ट के show को रीफ्रेश कर सकते हैं पेज देखें और देखें कि हमें क्या मिलता है: <पी> 
<पी> वही उपयोगकर्ता जिसके पास पहुंच थी, अब पोस्ट के दृश्य के दौरान वे क्या कर सकते हैं, इसमें सीमित है। समापन
<पी> इस दो-भाग वाली श्रृंखला के पहले भाग में, हमने प्राधिकरण रत्न एक्शन पॉलिसी के बारे में कुछ बुनियादी बातें सीखी हैं। <पी> दूसरे और अंतिम भाग में, हम कुछ और उन्नत उपयोग के मामलों का पता लगाएंगे। <पी> हैप्पी कोडिंग! <पी> पी.एस. यदि आप प्रेस से हटते ही रूबी मैजिक पोस्ट पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और एक भी पोस्ट न चूकें!
