10

मेरे पास नियंत्रकों और कार्रवाइयों पर प्राधिकरण विशेषताओं का उपयोग कर एक एएसपी.नेट एमवीसी अनुप्रयोग है। यह अच्छी तरह से काम कर रहा है लेकिन एक नई शिकन दिखाया गया है।एएसपी.नेट एमवीसी: एक क्रिया के अंदर प्राधिकरण - सुझाए गए पैटर्न या यह एक गंध है?

वस्तु: शिपमेंट

भूमिका: शिपिंग, लेखा, साधारण उपयोगकर्ता

शिपमेंट एक कार्यप्रवाह के माध्यम से ले जाता है। राज्य ए में इसे केवल शिपिंग द्वारा संपादित किया जा सकता है। राज्य बी में इसे केवल लेखा द्वारा संपादित किया जा सकता है।

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

तो मैं दो सवाल के साथ छोड़ दिया है:

1) क्या एक कार्रवाई के अंदर प्राधिकरण है एक अच्छा तरीका। नियंत्रक कार्रवाई किसी सेवा को कॉल करती है, और सेवा शिपमेंट ऑब्जेक्ट (अद्यतन मात्रा, अद्यतन दिनांक, आदि) को उचित कॉल करती है। मुझे यकीन है कि मैं शिपमेंट ऑब्जेक्ट को किसी भी प्राधिकरण आवश्यकताओं के अज्ञेयवादी होना चाहता हूं। दूसरी ओर, अगर मैं सेवा वस्तु को प्राधिकरण के बारे में जानना चाहता हूं या नहीं, तो मुझे वास्तविक समझ नहीं है। क्या इसके लिए कोई अच्छा पैटर्न है?

2) क्या मेरी समस्या वास्तव में खराब डिजाइन का एक लक्षण है? शिपमेंट नियंत्रक के बजाय मेरे पास स्टेटसशिप कंट्रोलर और स्टेटबिपमेंट कंट्रोलर होना चाहिए? मेरे पास शिपमेंट ऑब्जेक्ट में निर्मित कोई भी पॉलिमॉर्फिज्म नहीं है (राज्य सिर्फ एक enum है), लेकिन शायद मुझे और शायद नियंत्रकों को इसे प्रतिबिंबित करना चाहिए।

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

धन्यवाद!

+0

अपनी खुद की [अधिकृत] की तरह कार्रवाई शिपमेंट से संबंधित सामान के लिए फिल्टर क्यों नहीं बना? –

+0

निर्माण अपनी खुद की [अधिकृत] फिल्टर एक सच में, सच बुरा विचार हो सकता है, और यह कि ASP.NET MVC देव टीम वास्तव में वास्तव में बहुत दृढ़ता से –

+0

@Josh हतोत्साहित किया है में से एक है; मैं असहमत हूं। यह "वास्तव में, वास्तव में बुरा विचार" नहीं है, यह केवल एक है जिसे उचित देखभाल के साथ संपर्क किया जाना चाहिए। मैंने इसे हतोत्साहित करने के बारे में कोई सार्वजनिक लेख नहीं देखा है, कई 'वास्तव में और' दृढ़ता से 'बहुत कम है। केवल वास्तविक मेरे ज्ञान से 'पकड़ लिया' है कि आप, ढांचे के द्वारा उपलब्ध कराया अधिकृत विशेषता से प्राप्त करना है कि जिस तरह से आप सुनिश्चित कर सकते हैं क्योंकि यह है कि यह मज़बूती से सही जगह में निकाल दिया जाता चाहते हैं। – Paul

उत्तर

2

आपकी प्राधिकरण विशेषता शिपमेंट को कार्रवाई पैरामीटर या रूट डेटा से प्राप्त कर सकती है और फिर निर्णय ले सकती है।

नंबर 1 के लिए, ऐसे कई पैटर्न हैं जो डोमेन ऑब्जेक्ट्स में समृद्ध व्यवहार को सक्षम करते हैं। डबल-प्रेषण में, आप ऑब्जेक्ट पर किसी विधि के लिए एक सेवा अबास्ट्रक्शन (इंटरफ़ेस) का संदर्भ देते हैं। फिर यह अपनी बात कर सकता है। आप एक आवेदन सेवा भी लिख सकते हैं जो शिपमेंट लेती है और काम करता है।

नंबर 2 पर, जरूरी नहीं। आपको एक सेवा में "प्रासंगिक शिपमेंट" की अवधारणा को सारणी करने की आवश्यकता हो सकती है जो बताती है कि आप किस शिपमेंट संदर्भ में हैं। लेकिन मैं यज्ञ हूं कि जब तक आपको इसकी आवश्यकता न हो।

1

आप Rhino.Security पर एक नज़र डाल सकते हैं, इसका उपयोग इस तरह के परिदृश्यों में उपयोगकर्ता प्रमाणीकरण को लागू करने के लिए किया जा सकता है।

3

मुझे इसके भीतर और प्राधिकरण जांच करने के लिए एक एक्शन विधि के साथ कोई समस्या नहीं दिखाई दे रही है। आप जिस जुर्माना प्राधिकरण को ढूंढ रहे हैं, उसके लिए आप भूमिका प्रदाता का लाभ उठा सकते हैं। कृपया मेरे वाक्यविन्यास को यहां क्षमा करें - यह संभवतः किसी न किसी तरह की है और मैंने इसका परीक्षण नहीं किया है।

[Authorize(Roles="Shipping, Accounting")] 
public ActionResult Edit(int id) 
{ 
    Shipment shipment = repos.GetShipment(id); 


    switch (shipment.State) 
    { 
     case ShipmentState.A: 
     if (Roles.IsUserInRole("Shipping")) 
       return View(shipment); 
     else 
       return View("NotAuthorized"); 
     break; 
     case ShipmentState.B: 
     if (Roles.IsUserInRole("Accounting")) 
       return View(shipment); 
     else 
       return View("NotAuthorized"); 
     break; 
     default: 
       return View("NotAuthorized"); 
    } 
} 
+0

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

+0

यह उदाहरण लगभग राज्य पैटर्न कार्यान्वयन के लिए रोता है। – Paul

+1

हे हाँ यह निश्चित रूप से करता है! जितना सरल था, मैं यह सुनिश्चित करना चाहता था कि मैंने ओपी के प्रश्न को संबोधित किया, बजाय विवरण में फंस गया। –

1

जवाब उपरोक्त के अतिरिक्त, आप एक HttpUnauthorizedResult बजाय NotAuthorized के लिए अपने स्वयं के दृश्य बनाने के लौट सकते हैं।यह प्रवेश पृष्ठ पर रीडायरेक्ट और बस की तरह व्यवहार करेगा सामान्य [अधिकृत] विशेषता

संबंधित मुद्दे