एनटीयर ऐप में नेट सदस्यता

Question

आइए कहें कि मेरे पास एएसपी.NET एमवीसी ऐप है और यह ऐप (यूआई) एक बिजनेस लॉजिक लेयर (बीएलएल) संदर्भित करता है और बीएलएल मेरे डेटा एक्सेस लेयर (डीएएल) का संदर्भ देता है।

मैं प्राधिकरण के लिए कस्टम सदस्यता और भूमिका प्रदाता का उपयोग कर रहा हूं।

मैं यह निर्धारित करने की कोशिश कर रहा हूं कि परतों को मेरे सदस्यता प्रदाता को संदर्भित करने की आवश्यकता है।

MVC में आप निम्नलिखित तरीके से प्राधिकरण जांच कर सकते हैं:

public static bool IsRoleEditor(User user, Role userRole) 
    { 
    bool retValue = false; 

    if (user.Application.AppID == UserRole.Application.AppID) 
    { 
     if (Roles.IsUserInRole("ModifyRoles")) 
     { 
      retValue = true; 
     } 


    return retValue; 
    } 

:

[Authorize(Roles = "SomeRoleName")] 
public ActionResult Index() 
{ 
//do something 
} 

और मेरे BLL में मैं चाहते हो सकता है अगर एक उपयोगकर्ता के रूप में अच्छी तरह से एक भूमिका में है देखने के लिए जाँच करने के लिए

यदि मैं ऐसा करता हूं तो मुझे दोनों परतों में सदस्यता कक्षाओं को संदर्भित करना होगा और तत्काल करना होगा। क्या यह इस तरह के ऐप को आर्किटेक्ट करने का सही तरीका है? बहुत अनावश्यकता की तरह लगता है।

चूंकि मेरे पास बीएलएल है, इसलिए मैं "[प्राधिकरण (भूमिकाएं =" कुछ रोल नाम ")] गुणों का उपयोग करने से बचता हूं और इसके बजाय एमवीसी कोड के भीतर से एक बीएलएल फ़ंक्शन को कॉल करता हूं ताकि यह जांच सके कि उपयोगकर्ता भूमिका में है या नहीं? यदि मैं ऐसा करता हूं तो एमवीसी को अभी भी प्रमाणीकरण के लिए सदस्यता प्रदाता के संदर्भ की आवश्यकता है और इस तरह लॉगिन और अन्य एएसपी नियंत्रणों का लाभ उठाने के लिए, वैसे भी?

क्या मैं गलत दिशा में आधार और आगे बढ़ रहा हूं?

Answer 1

मेरी नजर में इस सदस्यता/भूमिका डिजाइन की एक कमजोरी है।

जिस तरह से मैं इसे प्राप्त करूंगा, उदाहरण के लिए एक वितरित एन-स्तरीय ऐप में यूआई और बीएलएल स्तरों पर भूमिका-आधारित प्रमाणीकरण करने के लिए, बीएलएल स्तर में एक सेवा का पर्दाफाश करना होगा जो प्रासंगिक बिट्स का खुलासा करता है (GetRolesForUser आदि) और सर्वर पर रोलप्रोवाइडर को कॉल करके कार्यान्वित किया जाता है।

फिर क्लाइंट पर एक कस्टम रोलप्रोवाइडर लागू करें जो बीएलएल द्वारा प्रकट सेवा को कॉल करके लागू किया गया है।

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

Answer 2

आईपीरियल इंटरफेस को लागू करने और परतों के चारों ओर फेंकने के लिए अपना उपयोगकर्ता ऑब्जेक्ट प्राप्त करें। फिर भी आप अंतर्निहित [Autorize] विशेषता का उपयोग कर सकते हैं।

हालांकि 3 साल पहले लिखा गया था और महल के बारे में this article मदद कर सकता है। यह आधिकारिक सामान आधा रास्ता नीचे शुरू होता है।

HTHS
चार्ल्स

Answer 3

बहुत बढ़िया सवाल है, मैं अपने आप को एक ही बात आज से पूछा। मेरे विचार में से एक था (लेकिन मुझे यकीन नहीं है कि यह जाने का सबसे अच्छा तरीका है) इंटरफ़ेस (पूर्व: आईरोलप्रोवाइडर) का उपयोग करना है जिसे आप अपनी एक्सेस का परीक्षण करने के लिए अपने बीएलएल में पास कर सकते हैं।

public static bool IsRoleEditor(User user, IRoleProvider rp) 
{ 
    return (rp.IsUserInRole(user,"ModifyRoles")); 
} 

इस के साथ, आप अभी भी अपने पहुँच अपने BLL में में सत्यापित करें, आप अपने तर्क की जाँच करने के लिए अपने इकाई परीक्षण में एक नकली उपयोग कर सकते हैं और तुम सिर्फ एक वर्ग बनाने की जरूरत है (या एक baseController कक्षा में यह लागू) आपकी एमवीसी वेबसाइट जो आईरोलप्रोवाइडर को कार्यान्वित करेगी और एएसपी.NET प्राधिकरण API का उपयोग करके उचित जांच करेगी।

आशा है कि इससे मदद मिलेगी।

Answer 4

रोल पहुंच सामान्य रूप से बीएलएल में नहीं होनी चाहिए। एक्सेस एक यूजर इंटरफेस जिम्मेदारी है।

इसके साथ ही, उपरोक्त पोस्टर के रूप में आईपीआरआईआरआईआर इंटरफेस का लाभ उठाने के लिए कहा गया है। आपके पास थ्रेड स्तर पर आईप्रिनेशन तक पहुंच है।

Thread.CurrentPrincipal 

Answer 5

क्यों अपने बीएलएल में भूमिकाएं पारित न करें ताकि आपके पास सदस्यता पर कोई निर्भरता न हो। या मार्टिनबी जैसे इंटरफेस का सुझाव दिया।

भविष्य में क्या होता है जब आपका स्टेक धारक प्रमाणीकरण के एक अलग रूप के साथ जाने का फैसला करता है और अब आप भूमिका ऑब्जेक्ट के साथ काम नहीं करते हैं?

उदाहरण:

IsRoleEditor(User user, string[] roles) 
{ 
    return roles.Contains("ModifyRoles"); 
} 

Answer 6

क्या आप एमवीसी का बिंदु नहीं खो रहे हैं। एमवीसी स्वाभाविक रूप से टायर में विभाजित है। मॉडल (डीएएल), नियंत्रक (बीएलएल), देखें (प्रेजेंटेशन)। यदि आप चाहें तो ये विभिन्न परियोजनाओं में जा सकते हैं लेकिन नियंत्रक के पास सभी व्यावसायिक तर्क हैं - आपको केवल रोलप्रोवाइडर तक पहुंचने की आवश्यकता है।

फिर यदि आप चाहते हैं तो आगे विभाजित करने के लिए भंडार, पैटर्न इत्यादि जैसे पैटर्न लागू करें।

डेवी

Answer 7

MVC नियंत्रक 'यूआई' कॉल करने के लिए निशान .. MVC में 'सी' अपने BLL की हिस्सा है बंद तरीका है, भले ही वह वर्ग जो आप कहेंगे संदर्भ देता है BLL। हालांकि, यह आपके प्रश्न का मुद्दा नहीं है।

मुझे लगता है कि मैं इस सवाल को हल करके इस समस्या को हल करूँगा, "क्या आपके 'यूआई' ऐप और आपके 'बीएलएल' के 100% अलगाव के लिए वास्तविक आवश्यकता है?"। यदि दोनों घटक सदस्य/भूमिका प्रदाताओं पर निर्भरता साझा करते हैं, तो ऐसा होने दें और काम पर आएं।

इस मामले में जहां आप अपना बीएलएल अनप्लग करते हैं और एक नए प्लग इन करते हैं, शायद .NET प्रदाता पर साझा निर्भरता होने के साथ आप कुछ भी रह सकते हैं। आप जानते हैं कि शायद यह ठीक है और आपका ऐप बस अलग नहीं हो सकता है।

मुझे लगता है कि जो जवाब ऊपर ज्यादा समझ में आता है हालांकि ...

Answer 8

मुझे लगता है कि तुम क्या कर रहे ठीक है।

प्राधिकरण और प्रमाणीकरण एक सेवा परत के भीतर रहना चाहिए, जो शायद आपके नियंत्रकों में पास हो गया है।

यदि नियंत्रक प्रिंसिपल और पहचान सेट करता है और फिर आप एमवीसी विशेषताओं के उपयोग के माध्यम से नियंत्रक में इसका उपयोग करते हैं तो यह एक अच्छा विचार लगता है।

इंटरफ़ेस के पीछे अपने एमवीसी सदस्यता प्रदाता को छिपाना अच्छा होगा, इस तरह आप इसे WinForms सदस्यता प्रदाता (उदाहरण के लिए) के लिए स्वैप कर सकते हैं और आपके नियंत्रकों का परीक्षण करने में सक्षम होंगे।