मैं अपने वेब एमवीसी एप्लिकेशन में एक्सेस कंट्रोल लिस्ट कैसे लागू कर सकता हूं?

Question

पहला प्रश्न

कृपया, क्या आप मुझे बता सकते हैं कि MVC में ACL को कितनी सरलता से लागू किया जा सकता है।

यहाँ नियंत्रक में Acl का उपयोग करने का पहला तरीका है ...

<?php
class MyController extends Controller {

  public function myMethod() {        
    //It is just abstract code
    $acl = new Acl();
    $acl->setController('MyController');
    $acl->setMethod('myMethod');
    $acl->getRole();
    if (!$acl->allowed()) die("You're not allowed to do it!");
    ...    
  }

}
?>

यह बहुत बुरा तरीका है, और यह माइनस है कि हमें प्रत्येक कंट्रोलर के तरीके में Acl कोड ऑफ कोड जोड़ना होगा, लेकिन हमें किसी अतिरिक्त निर्भरता की आवश्यकता नहीं है!

अगला तरीका सभी नियंत्रक विधियों को बनाना privateऔर एसीएल कोड को नियंत्रक की __callविधि में जोड़ना है ।

<?php
class MyController extends Controller {

  private function myMethod() {
    ...
  }

  public function __call($name, $params) {
    //It is just abstract code
    $acl = new Acl();
    $acl->setController(__CLASS__);
    $acl->setMethod($name);
    $acl->getRole();
    if (!$acl->allowed()) die("You're not allowed to do it!");
    ...   
  }

}
?>

यह पिछले कोड से बेहतर है, लेकिन मुख्य minuses हैं ...

• सभी नियंत्रक की विधियाँ निजी होनी चाहिए
• हमें प्रत्येक नियंत्रक की __call विधि में ACL कोड जोड़ना होगा।

अगला दृष्टिकोण Acl कोड को पैरेंट कंट्रोलर में डालना है, लेकिन हमें अभी भी सभी चाइल्ड कंट्रोलर के तरीकों को निजी रखना होगा।

उपाय क्या है? और सबसे अच्छा अभ्यास क्या है? मुझे निष्पादित करने के लिए अनुमति देने या अस्वीकार करने के लिए Acl फ़ंक्शन को कहां से कॉल करना चाहिए।

दूसरा सवाल

दूसरा प्रश्न Acl के उपयोग से भूमिका प्राप्त करने के बारे में है। आइए कल्पना करें कि हमारे पास मेहमान, उपयोगकर्ता और उपयोगकर्ता के दोस्त हैं। उपयोगकर्ता ने अपने प्रोफ़ाइल को देखने के लिए उपयोग को प्रतिबंधित कर दिया है कि केवल मित्र ही इसे देख सकते हैं। सभी अतिथि इस उपयोगकर्ता की प्रोफ़ाइल नहीं देख सकते हैं। तो, यहाँ तर्क है ..

• हमें यह सुनिश्चित करना होगा कि कहा जाने वाला तरीका प्रोफाइल है
• हमें इस प्रोफ़ाइल के स्वामी का पता लगाना होगा
• हमें पता लगाना है कि दर्शक इस प्रोफाइल का मालिक है या नहीं
• हमें इस प्रोफ़ाइल के बारे में प्रतिबंध संबंधी नियम पढ़ने होंगे
• हमें प्रोफाइल विधि को निष्पादित या निष्पादित नहीं करना है

मुख्य प्रश्न प्रोफ़ाइल के मालिक का पता लगाने के बारे में है। हम पता लगा सकते हैं कि केवल मॉडल के तरीके को निष्पादित करने वाले प्रोफ़ाइल का मालिक कौन है $ मॉडल-> getOwner (), लेकिन Acl के पास मॉडल तक पहुंच नहीं है। हम इसे कैसे लागू कर सकते हैं?

मुझे उम्मीद है कि मेरे विचार स्पष्ट हैं। मेरी अंग्रेजी के लिए खेद है।

धन्यवाद।

Comments

मुझे यह भी समझ में नहीं आता है कि आपको उपयोगकर्ता इंटरैक्शन के लिए "एक्सेस कंट्रोल लिस्ट" की आवश्यकता क्यों होगी। क्या आप ऐसा कुछ नहीं कहेंगे if($user->hasFriend($other_user) || $other_user->profileIsPublic()) $other_user->renderProfile()(और प्रदर्शित करें, "आपके पास इस उपयोगकर्ता की प्रोफ़ाइल तक पहुंच नहीं है" या ऐसा कुछ नहीं है? मैं इसे प्राप्त नहीं करता हूं।

— बटलर बटुक

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

— मरियो जूल

Answer 1

पहला भाग / उत्तर (ACL कार्यान्वयन)

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

class SecureContainer
{

    protected $target = null;
    protected $acl = null;

    public function __construct( $target, $acl )
    {
        $this->target = $target;
        $this->acl = $acl;
    }

    public function __call( $method, $arguments )
    {
        if ( 
             method_exists( $this->target, $method )
          && $this->acl->isAllowed( get_class($this->target), $method )
        ){
            return call_user_func_array( 
                array( $this->target, $method ),
                $arguments
            );
        }
    }

}

और यह होगा कि आप इस तरह की संरचना का उपयोग कैसे करते हैं:

// assuming that you have two objects already: $currentUser and $controller
$acl = new AccessControlList( $currentUser );

$controller = new SecureContainer( $controller, $acl );
// you can execute all the methods you had in previous controller 
// only now they will be checked against ACL
$controller->actionIndex();

जैसा कि आप देख सकते हैं, इस समाधान के कई फायदे हैं:

1. किसी भी वस्तु पर उपयोग किया जा सकता है, न कि केवल उदाहरण के लिए Controller
2. प्राधिकरण के लिए जाँच लक्ष्य वस्तु के बाहर होती है, जिसका अर्थ है:
   • मूल वस्तु पहुंच नियंत्रण के लिए जिम्मेदार नहीं है, एसआरपी का पालन ​​करती है
   • जब आपको "अनुमति अस्वीकृत" मिलती है, तो आप एक नियंत्रक, अधिक विकल्पों के अंदर बंद नहीं होते हैं
3. आप इस सुरक्षित उदाहरण को किसी अन्य ऑब्जेक्ट में इंजेक्ट कर सकते हैं , यह सुरक्षा को बनाए रखेगा
4. इसे लपेटो और इसे भूल जाओ .. आप दिखावा कर सकते हैं कि यह मूल वस्तु है, यह उसी पर प्रतिक्रिया करेगा

लेकिन , इस पद्धति के साथ एक प्रमुख मुद्दा यह भी है - यदि आप वस्तु की नकल और इंटरफेस (जो मौजूदा तरीकों को देखने के लिए भी लागू होता है) या कुछ विरासत श्रृंखला का हिस्सा है, तो आप मूल रूप से जांच नहीं कर सकते।

दूसरा भाग / उत्तर (वस्तुओं के लिए RBAC)

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

$this->acl->isAllowed( get_class($this->target), $method )

अनिवार्य रूप से आपके पास दो विकल्प हैं:

• प्रश्न में वस्तु के साथ एसीएल प्रदान करें। लेकिन आपको सावधान रहना होगा कि कानून के कानून का उल्लंघन न करें :

  $this->acl->isAllowed( get_class($this->target), $method )

• सभी प्रासंगिक विवरणों का अनुरोध करें और एसीएल को केवल वही प्रदान करें जो इसकी आवश्यकता है, जो इसे थोड़ा और अधिक इकाई-परीक्षण के अनुकूल बना देगा:

  $command = array( get_class($this->target), $method );
  /* -- snip -- */
  $this->acl->isAllowed( $this->target->getPermissions(), $command )

युगल वीडियो जो आपको अपने स्वयं के कार्यान्वयन में आने में मदद कर सकते हैं:

• वंशानुक्रम, बहुरूपता, और परीक्षण
• चीजों के लिए मत देखो!

साइड नोट्स

आपको लगता है कि एमवीसी में मॉडल क्या है, इसकी काफी सामान्य (और पूरी तरह से गलत) समझ है। मॉडल कोई क्लास नहीं है । यदि आपके पास वर्ग नाम FooBarModelया कुछ ऐसा है जो विरासत में मिला है AbstractModelतो आप इसे गलत कर रहे हैं।

उचित MVC में मॉडल एक परत है, जिसमें बहुत सारी कक्षाएं होती हैं। वर्गों के बड़े हिस्से को जिम्मेदारी के आधार पर दो समूहों में अलग किया जा सकता है:

- डोमेन व्यापार तर्क

(और पढ़ें : यहां और यहां ):

वर्गों के इस समूह के उदाहरण मूल्यों की गणना के साथ सौदा करते हैं, विभिन्न स्थितियों की जांच करते हैं, बिक्री नियमों को लागू करते हैं और बाकी सभी कार्य करते हैं जिन्हें आप "व्यावसायिक तर्क" कहते हैं। उनके पास कोई सुराग नहीं है कि डेटा कैसे संग्रहीत किया जाता है, जहां इसे संग्रहीत किया जाता है या भले ही भंडारण पहले स्थान पर मौजूद हो।

डोमेन बिजनेस ऑब्जेक्ट डेटाबेस पर निर्भर नहीं करता है। जब आप एक चालान बना रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि डेटा कहां से आता है। यह या तो SQL से या किसी दूरस्थ REST API या MSWord दस्तावेज़ के स्क्रीनशॉट से भी हो सकता है। व्यापार तर्क कोई परिवर्तन नहीं करता है।

- डेटा एक्सेस और स्टोरेज

इस समूह की कक्षाओं से बने उदाहरणों को कभी-कभी डेटा एक्सेस ऑब्जेक्ट कहा जाता है। आमतौर पर संरचनाएं जो डेटा मैपर पैटर्न को लागू करती हैं (एक ही नाम के ORM के साथ भ्रमित न करें .. कोई संबंध नहीं)। यह वह जगह है जहाँ आपका SQL स्टेटमेंट होगा (या शायद आपका DOMDocument, क्योंकि आप इसे XML में स्टोर करते हैं)।

दो प्रमुख भागों के अलावा, उदाहरणों / वर्गों का एक और समूह है, जिसका उल्लेख किया जाना चाहिए:

- सेवाएं

यह वह जगह है जहाँ आपके और 3 पार्टी घटक खेल में आते हैं। उदाहरण के लिए, आप "प्रमाणीकरण" को सेवा के रूप में सोच सकते हैं, जिसे आपके स्वयं के द्वारा प्रदान किया जा सकता है, या कुछ बाहरी कोड। "मेल प्रेषक" भी एक सेवा होगी, जो किसी डोमेन ऑब्जेक्ट को PHPMailer या SwiftMailer, या आपके अपने मेल-भेजने वाले घटक के साथ एक साथ बुन सकती है।

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

सेवाओं को बनाते समय आपको जो याद रखना है, वह यह है कि पूरी परत पतली होनी चाहिए । सेवाओं में कोई व्यावसायिक तर्क नहीं है। वे केवल डोमेन ऑब्जेक्ट, कंपोनेंट्स और मैपर्स को टटोलने के लिए हैं।

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

Comments

मैंने सिर्फ 5 मिनट में यह सीखा है कि मैं महीनों में इसकी तुलना कर रहा हूं। क्या आप इससे सहमत होंगे: पतले नियंत्रक उन सेवाओं को भेजते हैं जो दृश्य डेटा एकत्र करती हैं? इसके अलावा, यदि आप कभी भी सीधे प्रश्न स्वीकार करते हैं, तो कृपया मुझे एक संदेश भेजें।

— स्टीफन

मैं आंशिक रूप से सहमत हूं। दृश्य से डेटा का संग्रह MVC त्रय के बाहर होता है, जब आप Requestउदाहरण (या इसके कुछ एनालॉग) को इनिशियलाइज़ करते हैं । नियंत्रक केवल Requestउदाहरण से डेटा निकालता है और इसे उचित सेवाओं में से अधिकांश को पास करता है (इसमें से कुछ देखने के लिए भी जाता है)। सेवाएँ ऐसे ऑपरेशन करती हैं जो आपने उन्हें करने की आज्ञा दी थी। फिर, जब दृश्य प्रतिक्रिया उत्पन्न कर रहा होता है, तो यह सेवाओं से डेटा का अनुरोध करता है, और उस जानकारी के आधार पर, प्रतिक्रिया उत्पन्न करता है। कहा प्रतिक्रिया या तो HTML कई टेम्पलेट्स या सिर्फ एक HTTP स्थान हेडर से बनाया जा सकता है। नियंत्रक द्वारा निर्धारित स्थिति पर निर्भर करता है।

— tereško

सरलीकृत स्पष्टीकरण का उपयोग करने के लिए: नियंत्रक "लिखता है" मॉडल और देखने के लिए, मॉडल से "रीड्स" देखें। मॉडल लेयर वेब से संबंधित सभी पैटर्न में निष्क्रिय संरचना है जो MVC से प्रेरित है।

— tereško

@ स्टेफ़ेन, सीधे सवाल पूछने के लिए, आप हमेशा मुझे ट्विटर पर मैसेज कर सकते हैं। या फिर आप थोड़े लंबे "फॉर्म" के बारे में सवाल कर रहे थे, जिसे 140 वर्णों में नहीं किया जा सकता है?

— tereško

मॉडल से पढ़ता है: इसका मतलब है कि मॉडल के लिए कुछ सक्रिय भूमिका? मैंने ऐसा पहले कभी नहीं सुना। अगर आपकी प्राथमिकता है तो मैं आपको हमेशा ट्विटर के माध्यम से एक लिंक भेज सकता हूं। जैसा कि आप देख सकते हैं, ये प्रतिक्रियाएं जल्दी से वार्तालाप में बदल जाती हैं और मैं इस साइट और आपके ट्विटर अनुयायियों का सम्मान करने की कोशिश कर रहा था।

— स्टीफन

Answer 2

एसीएल और नियंत्रकों

सबसे पहले: ये अलग-अलग चीजें / परतें होती हैं। जैसा कि आप अनुकरणीय नियंत्रक कोड की आलोचना करते हैं, यह दोनों को एक साथ रखता है - सबसे स्पष्ट रूप से बहुत तंग।

tereško पहले से ही एक तरह से उल्लिखित है कि आप डेकोरेटर पैटर्न के साथ इसे और अधिक कैसे कम कर सकते हैं।

मैं उस मूल समस्या को देखने के लिए सबसे पहले एक कदम पीछे जाऊंगा, जिस पर आप चर्चा कर सकते हैं।

एक तरफ आप नियंत्रकों को चाहते हैं कि वे जो काम करने की आज्ञा दें (कमांड या एक्शन, उसे कमांड कहते हैं)।

दूसरी ओर आप अपने आवेदन में एसीएल लगाने में सक्षम होना चाहते हैं। इन ACL के कार्य का क्षेत्र होना चाहिए - यदि मैंने आपके प्रश्न को सही समझा है - आपके अनुप्रयोगों के कुछ आदेशों तक पहुँच को नियंत्रित करने के लिए।

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

आइए इस बिंदु को संक्षेप में बताएं कि हमारे पास क्या है:

• आदेश
• एसीएल
• उपयोगकर्ता

ACL घटक यहां केंद्रीय है: इसे कमांड के बारे में कम से कम कुछ जानने की जरूरत है (कमांड को सटीक रूप से पहचानने के लिए) और इसे उपयोगकर्ता की पहचान करने में सक्षम होना चाहिए। उपयोगकर्ताओं को आम तौर पर एक विशिष्ट आईडी द्वारा आसानी से पहचाना जाता है। लेकिन अक्सर वेबएप्लिकेशंस में ऐसे उपयोगकर्ता होते हैं जिनकी पहचान बिल्कुल नहीं होती है, जिन्हें अक्सर अतिथि, अनाम, हर कोई आदि कहा जाता है। इस उदाहरण के लिए हम मानते हैं कि ACL उपयोगकर्ता ऑब्जेक्ट का उपभोग कर सकता है और इन विवरणों को दूर कर सकता है। उपयोगकर्ता ऑब्जेक्ट अनुप्रयोग अनुरोध ऑब्जेक्ट के लिए बाध्य है और ACL इसका उपभोग कर सकता है।

एक कमांड की पहचान करने के बारे में क्या? एमवीसी पैटर्न की आपकी व्याख्या बताती है कि एक कमांड एक क्लासनाम और एक विधि नाम का यौगिक है। यदि हम अधिक बारीकी से देखते हैं तो कमांड के लिए तर्क (पैरामीटर) भी हैं। तो यह पूछने के लिए वैध है कि वास्तव में एक कमांड की पहचान क्या है? Classname, methodname, संख्याओं या तर्कों के नाम, यहां तक ​​कि किसी भी तर्कों के अंदर डेटा या इस सब का मिश्रण?

आपके ACL'ing में कमांड को पहचानने के लिए आपको किस स्तर के विवरण पर निर्भर करता है, यह बहुत भिन्न हो सकता है। उदाहरण के लिए, आइए इसे सरल रूप से रखें और निर्दिष्ट करें कि एक कमांड को क्लासनाम और विधि के नाम से पहचाना जाता है।

तो ये तीन भाग (ACL, Command और User) एक दूसरे से कैसे जुड़े हैं इसका संदर्भ अब अधिक स्पष्ट है।

हम कह सकते हैं, एक काल्पनिक एसीएल के साथ हम पहले से ही निम्नलिखित कर सकते हैं:

$acl->commandAllowedForUser($command, $user);

यहां देखें कि क्या होता है: कमांड और यूजर दोनों को पहचानने योग्य बनाकर, एसीएल यह काम कर सकता है। ACL का कार्य उपयोगकर्ता वस्तु और ठोस कमांड दोनों के काम से असंबंधित है।

केवल एक हिस्सा गायब है, यह हवा में नहीं रह सकता है। और यह नहीं है। इसलिए आपको उस स्थान का पता लगाने की आवश्यकता है जहां पहुंच नियंत्रण को किक करने की आवश्यकता है। आइए एक नज़र डालते हैं कि मानक वेबपेपलेशन में क्या होता है:

User -> Browser -> Request (HTTP)
   -> Request (Command) -> Action (Command) -> Response (Command) 
   -> Response(HTTP) -> Browser -> User

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

User -> Browser -> Request (HTTP)
   -> Request (Command)

अपने आवेदन में कुछ बिंदु पर आप जानते हैं कि एक विशिष्ट उपयोगकर्ता ने एक ठोस कमांड करने का अनुरोध किया है। आप पहले से ही यहाँ कुछ प्रकार का कार्य कर रहे हैं: यदि कोई उपयोगकर्ता एक कमांड का अनुरोध करता है जो मौजूद नहीं है, तो आप उस कमांड को निष्पादित करने की अनुमति नहीं देते हैं। तो जहां-जहां आपके आवेदन में होता है वहां "वास्तविक" एसीएल चेक जोड़ने के लिए एक अच्छी जगह हो सकती है:

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

वह स्थान जहाँ एक ठोस HTTPRequest की मैपिंग को कमांड पर मैप किया जाता है, अक्सर रूटिंग कहा जाता है । चूंकि रूटिंग में पहले से ही कमांड का पता लगाने का काम होता है, इसलिए यह जांचने के लिए इसे विस्तारित क्यों नहीं किया जाता है कि क्या कमांड को वास्तव में प्रति एसीएल की अनुमति है? उदाहरण के Router लिए एक एसीएल जागरूक राउटर का विस्तार करके RouterACL:। यदि आपका राउटर अभी तक नहीं जानता है User, तो यह Routerसही जगह नहीं है, क्योंकि ACL'ing के लिए केवल कमांड ही नहीं, बल्कि उपयोगकर्ता को भी पहचानना होगा। तो यह स्थान अलग-अलग हो सकता है, लेकिन मुझे यकीन है कि आप आसानी से उस स्थान का पता लगा सकते हैं, जिसे आपको बढ़ाने की आवश्यकता है, क्योंकि यह वह स्थान है जो उपयोगकर्ता और कमांड की आवश्यकता को पूरा करता है:

User -> Browser -> Request (HTTP)
   -> Request (Command)

उपयोगकर्ता शुरुआत के बाद से उपलब्ध है, कमान पहले के साथ Request(Command)।

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

तो बस चीजों को अलग रखें जो एक दूसरे से संबंधित नहीं हैं। सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल (एसआरपी) के थोड़ा रीवॉर्डिंग का उपयोग करें : कमांड को बदलने का केवल एक कारण होना चाहिए - क्योंकि कमांड बदल गया है। इसलिए नहीं कि अब आप अपने आवेदन में ACL'ing का परिचय देते हैं। इसलिए नहीं कि आप उपयोगकर्ता ऑब्जेक्ट स्विच करते हैं। इसलिए नहीं कि आप HTTP / HTML इंटरफ़ेस से SOAP या कमांड-लाइन इंटरफ़ेस पर माइग्रेट करते हैं।

आपके मामले में ACL एक कमांड तक पहुँच को नियंत्रित करता है, न कि कमांड को।

Comments

दो प्रश्न: CommandNotFoundResponse & CommandNotAllowedResponse: क्या आप इन्हें ACL वर्ग से राउटर या नियंत्रक के पास भेजेंगे और एक सार्वभौमिक प्रतिक्रिया की उम्मीद करेंगे? 2: यदि आप विधि + विशेषताएँ शामिल करना चाहते हैं, तो आप इसे कैसे संभालेंगे?

— स्टीफन

1: प्रतिक्रिया प्रतिक्रिया है, यहां यह एसीएल से नहीं है, लेकिन राउटर से है, एसीएल राउटर को प्रतिक्रिया प्रकार (नहीं पाया गया, विशेष रूप से निषिद्ध) का पता लगाने में मदद करता है। 2: निर्भर करता है। यदि आपका मतलब है क्रियाओं से पैरामीटर के रूप में विशेषताएँ, और आपको मापदंडों के साथ ACL'ing की आवश्यकता है, तो उन्हें ACL के अंतर्गत रखें।

— हक्रे

Answer 3

एक संभावना यह है कि आपके सभी नियंत्रकों को किसी अन्य वर्ग में लपेटना है जो नियंत्रक का विस्तार करता है और यह प्राधिकरण के लिए जाँच करने के बाद लिपटे उदाहरण के लिए सभी फ़ंक्शन कॉल को सौंपता है।

आप इसे डिस्पैचर में (यदि आपके आवेदन में वास्तव में एक है तो) अपस्ट्रीम, नियंत्रण विधियों के बजाय URL पर आधारित अनुमतियों को देख सकते हैं।

संपादित करें : क्या आपको डेटाबेस, एलडीएपी सर्वर आदि का उपयोग करने की आवश्यकता है, प्रश्न के लिए ऑर्थोगोनल है। मेरा कहना था कि आप नियंत्रक विधियों के बजाय URL पर आधारित एक प्राधिकरण लागू कर सकते हैं। ये अधिक मजबूत है क्योंकि आप आमतौर पर अपने URL (सार्वजनिक इंटरफ़ेस का URL क्षेत्र प्रकार) नहीं बदल रहे हैं, लेकिन आप अपने नियंत्रकों के कार्यान्वयन को भी बदल सकते हैं।

आमतौर पर, आपके पास एक या कई कॉन्फ़िगरेशन फ़ाइलें होती हैं जहाँ आप विशिष्ट प्रमाणीकरण विधियों और प्राधिकरण निर्देशों के लिए विशिष्ट URL पैटर्न मैप करते हैं। डिस्पैचर, नियंत्रक को अनुरोध भेजने से पहले, यह निर्धारित करता है कि क्या उपयोगकर्ता अधिकृत है और यदि नहीं है तो डिस्पैचिंग को रोक देता है।

Comments

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

— किर्ज़िला

अहा, आपका विचार आया। मुझे यह तय करना चाहिए कि मैं विधि को अंजाम दिए बिना क्रियान्वित करूं या नहीं! थम्स अप! आखिरी अनसुलझे सवाल - Acl से मॉडल कैसे एक्सेस करें। कोई विचार?

— किर्ज़िला

@ किर्ज़िला मेरे पास नियंत्रकों के साथ समान मुद्दे हैं। ऐसा लगता है कि निर्भरताएँ कहीं न कहीं होनी चाहिए। यहां तक ​​कि अगर ACL नहीं है, तो मॉडल परत के बारे में क्या? आप इसे एक निर्भरता होने से कैसे रोक सकते हैं?

— स्टीफन