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