Postharp: प्राधिकरण और प्रमाणीकरण

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

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



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

परीक्षण एप्लिकेशन को लोगों की सार्वजनिक सेवाओं के लिए कुछ अनुरोध भरने में मदद करने दें। यह एक वेब एप्लिकेशन हो सकता है, लेकिन हम सरलता के लिए WinForms एप्लिकेशन का उपयोग करेंगे। कोई भी उपयोगकर्ता अनुरोध फ़ॉर्म भर सकता है, हमारे मामले में यह एकमात्र पाठ क्षेत्र होगा। सिस्टम व्यवस्थापक किसी भी अनुरोध को हटा सकता है, एक साधारण उपयोगकर्ता केवल उन्हें बना सकता है और मौजूदा लोगों को देख सकता है।

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

public class GovtFormService : IGovtFormService{ private static readonly IList _govtFormsDatabase = new List(); public GovtFormService() { // build up some initial entries of the static list } public void SubmitForm(GovtForm form) { _govtFormsDatabase.Add(form); } public IEnumerable GetAllForms() { return _govtFormsDatabase; } public GovtForm GetFormById(Guid guid) { return _govtFormsDatabase.FirstOrDefault(form => form.FormId == guid); } } 

यहां, हम केवल सेवा के साथ फ़ॉर्म को जोड़ते हैं और सेवा से बटन दबाए जाने के तरीकों को असाइन करते हैं ताकि अंततः मूल एप्लिकेशन प्राप्त हो सके। हालाँकि, आवश्यकताएँ स्पष्ट रूप से इंगित करती हैं कि उपयोगकर्ता को केवल उनके अनुरोधों को देखने में सक्षम होना चाहिए। GetFormById वर्तमान में कोई चेक नहीं करता है। आप कई शर्तें जोड़ सकते हैं, लेकिन तुरंत एक ऐसा पहलू बनाना बेहतर होगा जिसका उपयोग हर जगह किया जा सके।

 [Serializable] public class AuthorizeReturnValueAttribute : OnMethodBoundaryAspect{    [NonSerialized] private IAuth Auth;    public override void RuntimeInitialize(System.Reflection.MethodBase method) {        Auth = new AuthService();    }    public override void OnSuccess(MethodExecutionArgs args) {        var singleForm = args.ReturnValue as GovtForm;        if (singleForm != null) {            if(Auth.CurrentUserHasPermission(singleForm, Permission.Read)) {                MessageBox.Show(                 "You are not authorized to view the details of that form",                 "Authorization Denied!");                args.ReturnValue = null;            }            return;        }    } } 

इसे लागू करने का एक तरीका यह जांचना है कि क्या इंटरसेप्टेड विधि एक GovtForm प्रकार लौटाती है। यदि हाँ, तो जाँच लें कि क्या यह अनुरोध प्रपत्र उपयोगकर्ता का है। ध्यान दें कि I प्रामाणिक के प्रकार को गैर-क्रमिक के रूप में चिह्नित किया गया है, और यह ओवरराइड RuntimeInitialize पद्धति में आरंभिक है। इस मामले में, हार्डकोड का उपयोग किया गया था, लेकिन आप IoC कंटेनर को सेवा लोकेटर के रूप में उपयोग कर सकते हैं (डिपेंडेंट इंजेक्शन के बारे में अनुवाद देखें)।

पहलू में कुछ और कोड जोड़ें ताकि आप उन तरीकों के साथ काम कर सकें जो GovtForm संग्रह को वापस करते हैं और वर्तमान उपयोगकर्ता के लिए उपलब्ध अनुरोध फ़ॉर्म को फ़िल्टर करते हैं।

 var formCollection = args.ReturnValue as IEnumerable; if (formCollection != null) {    args.ReturnValue = formCollection            .Where(f => Auth.CurrentUserHasPermission(f, Permission.Read));    return; } 

सिवाय इसके कि सरकार UserName संपत्ति को लागू करती है, GovtForm वर्ग अचूक है। आप प्रत्येक व्यावसायिक ऑब्जेक्ट के लिए ISecurable इंटरफ़ेस जोड़ सकते हैं जिसे आप प्रस्तावित दृष्टिकोण के अनुसार संसाधित करना चाहते हैं। तब करेंटयूज़रहैर्सपर्शन विधि को पुन: लिखने योग्य प्रकार के तर्क को स्वीकार करने के लिए फिर से लिखा जा सकता है। उसके बाद, यह केवल उन सेवाओं और रिपॉजिटरी को अधिकृत करता है जो एक एकल व्यावसायिक वस्तु या उनके संग्रह को लौटाते हैं, ताकि उपयोगकर्ता केवल उनके अनुरोध प्रपत्र देखता है। इस दृष्टिकोण के साथ, आपको यूआई या सेवाओं के लिए कोड को महत्वपूर्ण रूप से बदलने की आवश्यकता नहीं है।

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

यह कैसे करना है:

1. ब्याज के पहलुओं के लिए ProvAspectRoleAttribute विशेषता लागू करें। भूमिका एक स्ट्रिंग हो सकती है, या आप PostSharp स्थान से StandardRoles गणन का उपयोग कर सकते हैं।
2. निर्भरता के प्रकार और जिस भूमिका पर वे निर्भर करते हैं, उसे इंगित करने के लिए पहलू के पहलू पर AspectRoleD dependencyAttribute विशेषता को लागू करें।

ऊपर वर्णित समस्या को हल करने के लिए, आपको कुछ इस तरह के पहलुओं पर एट्रीब्यूट्स लागू करने की आवश्यकता है:

 [Serializable] [AspectRoleDependency(AspectDependencyAction.Order,    AspectDependencyPosition.Before, StandardRoles.Caching)] public class AuthorizeReturnValueAttribute : OnMethodBoundaryAspect{ } [Serializable] [ProvideAspectRole(StandardRoles.Caching)] public class CachingAttribute : OnMethodBoundaryAspect {    public override void OnEntry(MethodExecutionArgs args) {        // do caching stuff    }    public override void OnSuccess(MethodExecutionArgs args) {        // do caching stuff    } } 

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

और यहां बताया गया है कि GetAllForms पद्धति का कोड दोनों पहलुओं पर लागू होने के बाद कैसे दिखेगा (रिफ्लेक्टर की भावना में प्रोग्राम का उपयोग करके प्राप्त किया जाता है):

 public IEnumerable GetAllForms(){    MethodExecutionArgs CS$0$2__aspectArgs = new MethodExecutionArgs(null, null);    <>z__Aspects.a1.OnEntry(CS$0$2__aspectArgs);    IEnumerable CS$1$1__returnValue = _govtFormsDatabase;    <>z__Aspects.a1.OnSuccess(CS$0$2__aspectArgs);    CS$0$2__aspectArgs.ReturnValue = CS$1$1__returnValue;    <>z__Aspects.a0.OnSuccess(CS$0$2__aspectArgs);    return (IEnumerable) CS$0$2__aspectArgs.ReturnValue; } 

और तुलना के लिए, कोड, अगर सब कुछ सही है और AspectD dependencyPosition को पहले बदलें:

 public IEnumerable GetAllForms(){    <>z__Aspects.a1.OnEntry(null);    MethodExecutionArgs CS$0$2__aspectArgs = new MethodExecutionArgs(null, null);    IEnumerable CS$1$1__returnValue = _govtFormsDatabase;    CS$0$2__aspectArgs.ReturnValue = CS$1$1__returnValue;    <>z__Aspects.a0.OnSuccess(CS$0$2__aspectArgs);    CS$1$1__returnValue = (IEnumerable) CS$0$2__aspectArgs.ReturnValue;    <>z__Aspects.a1.OnSuccess(null);    return CS$1$1__returnValue; } 

ध्यान दें कि a1 (कैशिंग) और a0 (प्राधिकरण) स्वैप किए गए हैं।

PostSharp पहलू निर्भरताओं को अनुकूलित करने के लिए व्यापक विकल्प प्रदान करता है। अपने निपटान में निर्भरता को हल करने के लिए 5 क्रियाएं: कम्यूट, संघर्ष, आदेश, आवश्यकता और कोई नहीं। इसके अतिरिक्त, यदि आप StandardRoles गणन में पर्याप्त नहीं हैं, तो आप अनंत संख्या में भूमिकाएँ बना सकते हैं। सौभाग्य से, आपको अक्सर इन सुविधाओं की आवश्यकता नहीं होगी, लेकिन समय आने पर उनके बारे में जानना अच्छा होगा। सबसे अच्छी बात यह है कि आप आराम कर सकते हैं, यह जानकर कि टीम का सबसे नया सदस्य भी यूआई पर डेटा नहीं देगा, जिसे प्राधिकरण की आवश्यकता है, क्योंकि इससे कोई फर्क नहीं पड़ेगा कि वह किस क्रम में कोड के पहलुओं को लागू करता है।

मैथ्यू डी। पर सॉफ्टवेयर इंजीनियर ग्रूव्स   बताने वाला । उनका ब्लॉग mgroves है । com ।

PostSharp : लॉगिंग और ऑडिटिंग , कैशिंग , विलंबित निर्भरता लोडिंग ।