Heimdallr: मॉडल क्षेत्र सुरक्षा और नया CanCan

अधिकांश वेब-परियोजनाओं को ब्राउज़र-आधारित अनुप्रयोगों में बदलने की प्रक्रिया में, कई सवाल उठते हैं। और उनमें से एक सबसे महत्वपूर्ण है अनावश्यक कोड के बिना एक्सेस अधिकारों का प्रसंस्करण। इस विषय पर विचार हमें एक बड़ी समस्या की ओर ले गए: ActiveRecord ( Egor , hello!!) के लिए मॉडल के क्षेत्र स्तर पर सुरक्षा को लागू करने का कोई सुविधाजनक तरीका नहीं है। कैनकन नियंत्रक स्तर पर प्रतिबंध जोड़ता है, लेकिन सभी समस्याओं को हल करने के लिए यह बहुत अधिक स्तर है।

थोड़ी हताशा के बाद, हमने दो प्यारे रत्न लिखे। हेमदाल्र (हेमदल) और उसके विस्तार हेमदाल्र से मिलो :: संसाधन । वे आपके मॉडलों में शांति और सुरक्षा लाएंगे।

Heimdallr

आइए पहले समस्या को गहराई से देखें। परियोजनाओं का एक बड़ा हिस्सा वास्तव में REST नियंत्रकों के अभिगम नियंत्रण के साथ सुरक्षा को समान करता है। बड़ी परियोजनाएं अक्सर मॉडल के नीचे जाती हैं ताकि कोड डुप्लिकेट न हो। और इसलिए कि नियंत्रकों में कार्यों की संख्या असहनीय रूप से बड़ी नहीं हो जाती है, कभी-कभी वे एक्सेस फ़ील्ड को नियंत्रित करने के लिए नीचे जाते हैं।



कई रीस्टफुल एप्लिकेशन के लिए, 1 और 2 का स्तर समान है। इसलिए, नीचे पंक्ति में, हमारे पास है:

1. मॉडल एक्सेस
2. मॉडल क्षेत्रों तक पहुंच

इसी समय, परियोजना के विकास के साथ खेतों तक पहुंच के प्रबंधन का महत्व तेजी से बढ़ रहा है। और हाल ही में Github बदनाम उदाहरण फील्ड्स के निहितार्थ का एक प्रमुख उदाहरण है? लेकिन इसकी जरूरत किसे है! ”

यहाँ एक उदाहरण है कि कैसे हेमदाल्र इसके साथ मदद कर सकता है:

class Article < ActiveRecord::Base include Heimdallr::Model belongs_to :owner, :class_name => 'User' restrict do |user, record| if user.admin? #      scope :fetch scope :delete can [:view, :create, :update] else #      -  scope :fetch, -> { where('owner_id = ? or secrecy_level < ?', user.id, 5) } scope :delete, -> { where('owner_id = ?', user.id) } # ...        # (    )... if record.try(:owner) == user can :view can :update, { secrecy_level: { inclusion: { in: 0..4 } } } else can :view cannot :view, [:secrecy_level] end # ...      ,   . can :create, %w(content) can :create, { owner_id: user.id, secrecy_level: { inclusion: { in: 0..4 } } } end end end 

मॉडलों के अंदर एक साधारण डीएसएल का उपयोग करते हुए, हम स्वयं और अपने क्षेत्रों के लिए मॉडल के उपयोग पर प्रतिबंध की घोषणा करते हैं। Heimdallr अपने मॉडल को .restrict विधि का उपयोग करके .restrict है। इस पद्धति को कॉल करने से मॉडल वर्ग को एक प्रॉक्सी आवरण में लपेट दिया जाएगा जिसे आप पूरी तरह से पारदर्शी रूप से उपयोग कर सकते हैं।

 Article.restrict(current_user).where(:typical => true) 

ध्यान दें कि Class.restrict कॉल करने के लिए, ब्लॉक का दूसरा पैरामीटर शून्य होगा। इसलिए, सभी जांचें जो वर्तमान वस्तु के क्षेत्रों की स्थिति पर निर्भर करती हैं, उन्हें .try(:field) में लपेटा जाना चाहिए।

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

विचारों के साथ समस्या को हल करने के लिए, हेमडालर स्पष्ट और निहित दो रणनीतियों को लागू करता है। डिफ़ॉल्ट रूप से, हेमडाल्र एक स्पष्ट व्यवहार मॉडल का पालन करेगा। और यहाँ एक वैकल्पिक व्यवहार है:

 article = Article.restrict(current_user).first @article = article.implicit @article.protected_thing # => nil 

लगभग। लेख की शुरुआत में, मैंने Canan का उल्लेख किया। लेकिन क्या वह समस्या को मौलिक रूप से अलग तरीके से हल नहीं करता है?

कैनकैन

कई रेल परियोजनाओं के लिए, "सुरक्षा" शब्द कनक मणि का एक पर्याय है। कैनकन वास्तव में एक युग था और यह अभी भी बहुत अच्छा काम करता है। लेकिन उसके पास कई समस्याएं हैं:

• कैनकन की कल्पना एक ऐसे उपकरण के रूप में की गई थी जो मॉडल के साथ काम नहीं करता है। यह एक वास्तुकला प्रदान करता है जिसमें REST नियंत्रकों की सुरक्षा की जाती है, और एक हमलावर केवल मॉडलों तक नहीं पहुंच पाता है। कभी-कभी यह रणनीति अच्छी होती है, कभी-कभी नहीं। लेकिन तथ्य यह है कि आप खेतों में नहीं जा सकते, चाहे आप कितनी भी कोशिश कर लें। Canan बस नहीं जानता और खेतों के बारे में कुछ भी नहीं जान सकता।
• शाखा 1.x मृत है और समर्थित नहीं है। इसमें कई अप्रिय कीड़े हैं जो इसे नामपेक्स के साथ मुश्किल मामलों में काम करने से रोकते हैं। एक शाखा 2.x निषेधात्मक रूप से लंबी विकसित होती है।

हमने हेमडाल्र को एक मॉडल नियंत्रण उपकरण के रूप में विकसित करना शुरू किया, लेकिन व्यवहार में यह पता चला कि हमारे पास नियंत्रकों को सीमित करने के लिए पर्याप्त डेटा था। इसलिए, हमने लिया और लिखा हेमदल्लर :: संसाधन।

हेमडाल्र का यह हिस्सा जितना संभव हो सके कैनकन की नकल करता है। आपके पास समान load_and_authorize फ़िल्टर है और यह इस प्रकार काम करता है:

• यदि स्कोप: क्रिएट को वर्तमान संदर्भ के लिए घोषित नहीं किया गया है (और इसलिए आप इकाइयाँ नहीं बना सकते हैं), तो आप नए और बना नहीं सकते
• यदि आपके पास स्कोप नहीं है: अपडेट करें, आप एडिट और अपडेट नहीं कर सकते।
• गुंजाइश के लिए एक समान दृष्टिकोण: नष्ट
• कार्रवाई में, आपको तुरंत संरक्षित इकाई मिलती है, और इसलिए आप मैन्युअल रूप से restrict कॉल करना नहीं भूल restrict

यह इस तरह दिखता है:

 class ArticlesController < ApplicationController include Heimdallr::Resource load_and_authorize_resource #    : # # load_and_authorize_resource :resource => :article #  : # # routes.rb: # resources :categories do # resources :articles # end # # load_and_authorize_resource :through => :category def index # @articles   restrict' end def create # @article   restrict' end end 

बाकी एपीआई प्रदाता

कहानी की शुरुआत में, मैंने विचार की जड़ के बारे में बात की, क्लाइंट एप्लिकेशन और सर्वर के बीच पहुंच अधिकारों का सिंक्रनाइज़ेशन REST-API। और इसलिए हमने किन सम्मेलनों का समापन किया।

कल्पना करें कि आपके पास भूमिकाओं के साथ एक सरल CRUD इंटरफ़ेस है जिसे आपको क्लाइंट JS एप्लिकेशन के रूप में कार्यान्वित करने की आवश्यकता है। इस स्थिति में, सर्वर पर आपके पास अनुक्रमणिका / बनाने / अद्यतन / नष्ट करने के साथ REST है। पहुँच अधिकार निम्नलिखित प्रश्न पूछते हैं:

1. इंडेक्स के माध्यम से मुझे कौन सी इकाइयाँ मिल सकती हैं?
2. मैं उनमें से किसे बदल सकता हूं?
3. मैं किन लोगों को हटा सकता हूं?
4. क्या मैं एक नई इकाई बना सकता हूं?
5. अपडेट करते समय मैं कौन से फ़ील्ड सेट कर सकता हूं?
6. बनाते समय मैं कौन से फ़ील्ड सेट कर सकता / सकती हूं?

पहला प्रश्न हेमदल्लर ने स्वभाव से तय किया है। आपने बस वांछित गुंजाइश और सभी निर्धारित किया है। कोई भी व्यक्ति कुछ भी नहीं देखता है। बाकी के बारे में। अपने आखिरी लेख में, मैंने बात की कि हम RSON प्रदाताओं के लिए JSON अभ्यावेदन कैसे प्रस्तुत करते हैं। एक ही तकनीक का उपयोग करके, निम्नलिखित क्षेत्रों के साथ विस्तार करना बहुत आसान है:

 {modifiable: self.modifiable?, destroyable: self.destroyable?} 

क्या मैं बना सकता हूं? और किन क्षेत्रों के साथ?

REST API के लिए, नया तरीका लगभग बेकार है। और यह निर्धारित करने के लिए एक शानदार जगह है कि क्या हम कुछ बना सकते हैं और वास्तव में क्या। उदाहरण के लिए, इस तरह:

 Article.restrictions(current_user).allowed_fields[:create] 

यदि हम बिल्कुल नहीं बना सकते हैं, तो Heimdallr :: संसाधन इस अनुरोध का उत्तर त्रुटि के साथ देगा। अन्यथा, हमें भरने के लिए उपलब्ध फ़ील्ड की एक सूची मिलती है।

.creatable? भी एक .creatable? विधि की घोषणा .creatable? , ताकि इसे REST के माध्यम से फेंका जा सके।

क्या मैं अपडेट कर सकता हूं?

विचार सृष्टि के समान है। केवल इस बार हम संपादन विधि की घोषणा करेंगे:

 Article.restrictions(current_user).allowed_fields[:update] 

निष्कर्ष में

Heimdall और इसके एक्सटेंशन का उपयोग करते हुए, Heimdallr :: संसाधन, आपको कोड में अनावश्यक कचरा के बिना आसानी से अधिकार का प्रबंधन करने में मदद करेगा। और, महत्वपूर्ण रूप से, आपको अपने REST-API के लिए अतिरिक्त जादू मिलता है। याद रखें, खोमेकोव आपको देख रहा है!

ಠ_ಠ