अभिगम नियंत्रण के लिए मानक प्रथाओं (डिजाइन पैटर्न)

9

मैं अपने इंटरफ़ेस डिज़ाइन को देख रहा हूं और मैं यह तय करने के लिए संघर्ष कर रहा हूं कि रोल-आधारित एक्सेस कंट्रोल को लागू करने के लिए सबसे "सही" तरीका क्या है, एक userऔर subjectजिसे userएक्सेस करना चाहते हैं।

जहां तक मैं देख सकता हूं कि मेरे पास तीन मुख्य विकल्प हैं (एक चौथे के साथ पहले तीन का एक बार्डरडाइजेशन है और एक पांचवें का चौथा होने के कारण):

उन subjectअनुमतियों की सूची के साथ क्वेरी करें जिनमें user-subject.allowAccess(user.getPermissionSet)
उन userअनुमतियों की सूची के साथ क्वेरी करें जिनकी subjectआवश्यकता है -user.hasPermissionTo(subject.getRequiredPermissions())
अनुमतियों के चौराहों का पता लगाने के लिए एक तृतीय-पक्ष क्वेरी करें - accessController.doPermissionSetsIntersect(subject.permissionSet, user.getPermissionSet())
तृतीय पक्ष वर्ग के "निर्णय" को प्रस्तुत करते हुए क्वेरी या तो subject/user
यदि एक्सेस की अनुमति नहीं है, तो किसी त्रुटि userको एक्सेस करने subjectऔर फेंकने का प्रयास करें

मैं विकल्प चार की ओर झुक रहा हूं - क्या subjectकोई accessControllerफ़ील्ड शामिल है , जहां subject.userMayAccess(User user)ऑपरेशन को ला को कॉल करने के लिए कॉल किया गया है:

class Subject {
    public function display(user) {
        if(!accessController.doPermissionSetsIntersect(this.permissionSet, user.getPermissionSet())) {
            display403(); //Or other.. eg, throw an error..
        }
    }
}

.. लेकिन फिर इससे और सवाल खड़े होते हैं:

accessControllerएक क्षेत्र बनाम एक स्थिर वर्ग होना चाहिए ..?
subject पता होना चाहिए कि इसे देखने के लिए किन अनुमतियों की आवश्यकता है?
कॉलिंग के संबंध में कम से कम ज्ञान का सिद्धांत कहां से आता है subject.display()? क्या subject.display()कभी कॉल करने वालों को पता होना चाहिए कि एक्सेस कंट्रोल लागू है? (जहां subject.display()एक अंतिम "टेम्पलेट विधि" है)
है subject.display()अभिगम नियंत्रण प्रबंधन, एक अपवाद है, जहां उपयोगकर्ता के लिए आवश्यक अनुमति नहीं है फेंक?

इस स्थिति में "सर्वश्रेष्ठ अभ्यास" क्या माना जाएगा? वास्तव में चेक के प्रदर्शन की जिम्मेदारी कहां होनी चाहिए?

जैसा कि यह कुछ हद तक एक अकादमिक बहिष्कार है जो फिर कार्यान्वयन में प्रगति करेगा, डिजाइन पैटर्न के संदर्भ की सराहना की जाएगी।

design single-responsibility access-control

— Kwah
स्रोत

7

सबसे अच्छा अभ्यास सुरक्षित क्षेत्रों के लिए कॉल को अवरोधन करने के लिए इंटरसेप्टर पैटर्न के रूप में जाना जाता है।

यह एओपी या क्रॉस कटिंग चिंताओं के उपयोग से प्राप्त किया जा सकता है जो आपके प्रवेश बिंदुओं पर लागू होता है।

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

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

यदि आप AOP या इंटरसेप्टर पैटर्न दृष्टिकोण का उपयोग करते हैं, तो यह किसी भी आवश्यक अपवाद को फेंक देगा, और यह किसी भी अपवाद को संभालने के लिए क्लाइंट (कॉलर) पर निर्भर होगा।

इस तरह आप अपने ग्राहक, सेवा और प्रमाणीकरण कोड को बिना किसी ज्ञान या कार्यक्षमता के परस्पर अलग रखते हैं।

— sweetfa
स्रोत

1

एओपी: पहलू उन्मुख प्रोग्रामिंग

— mbigras

2

मुझे लगता है कि आपका विकल्प 3 सबसे नज़दीकी है, लेकिन पूछताछ करने userऔर subjectउनके अनुमति सेट के बारे में आपको पास userऔर subjectएक्सेस कंट्रोलर के पास जाना चाहिए ।

class Subject {
    public function display(user) {
        if(!accessController.checkAccess(this, user, AccessControl.Read)) {
            display403(); //Or other.. eg, throw an error..
        }
    }
}

एक्सेस नियंत्रक को अनुमति सेट और जाँच दोनों के लिए जिम्मेदार होना चाहिए यदि एक्सेस पर्याप्त है। इस तरह आप अपने एक्सेस कंट्रोलर में स्टोरेज लॉजिक और चेकिंग लॉजिक दोनों को अलग करते हैं, यूजर और सब्जेक्ट दोनों से अलग।

अन्य तत्व संभवतः आपके उदाहरण से गायब है जो ऑपरेशन किया जा रहा है। कुछ उपयोगकर्ताओं को कुछ डेटा नहीं बल्कि,,, अद्यतन करने के लिए पढ़ने के लिए हटाना निष्पादित आदि अधिकार हो सकता है तो तुम एक हो सकता है checkAccessतीन मापदंडों के साथ पहुँच नियंत्रक पर विधि: user, subject, operation। आप कुछ अतिरिक्त जानकारी प्रदान करने के बारे में भी जानकारी प्रदान करने के लिए वापस आ checkAccessसकते हैं क्यों कि एक्सेस की अनुमति नहीं दी गई थी।

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

चाहे आप एओपी का उपयोग करें या कुछ बायलरप्लेट कोड का उपयोग करें, यह मेरी राय में, कम महत्वपूर्ण है।

— रोरी
स्रोत