आप ASP.Net में फ़ील्ड स्तरीय सुरक्षा कैसे प्राप्त करते हैं?

Question

मेरे पास 20 फ़ील्ड वाले एक .aspx फॉर्म है जो उपयोगकर्ताओं की भूमिका और ऑर्डर रिकॉर्ड की स्थिति के आधार पर अक्षम होना चाहिए। वर्तमान में आवेदन में 5 भूमिकाएं और 3 स्थिति हैं, इसलिए मेरे पास 300 अलग-अलग संभावित स्थितियां हैं जिनके लिए मुझे खाता है।

मेरा पहला विचार तालिका में प्रत्येक क्रमपरिवर्तन को स्टोर करना है, फिर फ़ील्ड को लोड करते समय फ़ील्ड सेट करते समय फ़ील्ड सेट करें। क्या कोई बेहतर तरीका है? कृपया ध्यान दें, मैं .NET 2.0 का उपयोग कर रहा हूं और एमवीसी नहीं।

Answer 1

मैं शायद प्रत्येक फ़ील्ड का विवरण संग्रहीत करता हूं, और फिर भूमिकाएं और स्थिति जो उन्हें संपादित कर सकती है, और इसे इस तरह से कर सकती है।

सिस्टम के नियम क्या हैं? असल में, क्या वास्तव में 300 संभव स्थितियां हैं? या यह है कि वास्तव में कुछ फ़ील्ड केवल कुछ स्थिति के लिए संपादन योग्य हैं, और फिर केवल कुछ भूमिकाएं उन क्षेत्रों को संपादित कर सकती हैं? या यह है कि कुछ फ़ील्ड कुछ भूमिकाओं के लिए भी उपलब्ध हैं?

अगर यह पूर्व की अधिक है मैं शायद कुछ इस तरह होगा:

तीन प्राथमिक तालिकाओं (विस्तार करने के लिए इसे आसान बना देता है यदि आप एक क्षेत्र, भूमिका या स्थिति को जोड़ने):

• फील्ड्स
• भूमिकाओं
• स्थिति

फिर दो लिंक टेबल:

• Field.Id और Role.Id
• Field.Id और Status.Id

किसी भी आदेश और उपयोगकर्ता आप तो पा सकते हैं जो फील्ड्स आदेश की वर्तमान स्थिति के लिए संपादित किए जाने योग्य के लिए

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

यदि आपके पास कोई समस्या है जहां भूमिका स्थिति को ओवरराइड कर सकती है, तो आप फ़ील्ड/रोल टेबल में एक बुलियन भी स्टोर कर सकते हैं, यह दर्शाता है कि फ़ील्ड स्थिति के बावजूद उपलब्ध हो सकता है या नहीं।

Answer 2

मैं इसे प्राप्त करने के लिए तीसरे पक्ष के ढांचे का उपयोग करने का सुझाव देता हूं। हम अपनी परियोजनाओं में CSLA ढांचे का उपयोग करते हैं। यह हमें क्षेत्र स्तर पर प्राधिकरण सेट करने की अनुमति देता है।

Answer 3

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

Private mFirstName As String = "" 
Public Property FirstName() As String 
    <System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _ 
    Get 
     CanReadProperty("FirstName", True) 
     Return mFirstName 
    End Get 
    <System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _ 
    Set(ByVal value As String) 
     CanWriteProperty("FirstName", True) 
     If value Is Nothing Then value = "" 
     If Not mFirstName.Equals(value) Then 
      mFirstName = value 
      PropertyHasChanged("FirstName") 
     End If 
    End Set 
End Property 

सूचना कॉल। दूसरा पैरामीटर निर्दिष्ट करता है कि यदि उपयोगकर्ता विशिष्ट पढ़ने/लिखने के संचालन को करने के लिए अधिकृत नहीं है तो विधि को अपवाद फेंकना चाहिए।

CanReadProperty और CanWriteProperty के कार्यान्वयन ढांचे के आधार वर्ग द्वारा प्रदान किए जाते हैं लेकिन पूरे सीएसएलए ढांचे को अपनाने के बिना पुन: उत्पादित किया जाना चाहिए। कार्यान्वयन AuthorizationRules डेटा संरचना की जांच करता है जो परिभाषित करता है कि किसने अनुमति/अस्वीकार किया है भूमिकाओं के आधार पर पहुंच पढ़ें/लिखें।अक्सर, AuthorizationRules संरचना वस्तु निर्माण के दौरान आबादी है।

उसी प्रस्तुति के लिए CanReadProperty और CanWriteProperty विधियों का खुलासा करने वाला-स्तरीय आपको वर्तमान उपयोगकर्ता के पहुंच अधिकारों के आधार पर UI तत्वों को सक्षम/अक्षम करने की अनुमति देता है। उदाहरण के लिए:

FirstNameTextBox.ReadOnly = Not CanWriteProperty("FirstName", false) 

उम्मीद है कि यह जानकारी आपको अपने कार्यान्वयन के विकास के लिए एक अच्छा प्रारंभिक बिंदु प्रदान करेगी। यदि आप सीएसएलए के बारे में अधिक जानने में रुचि रखते हैं तो Expert C# 2008 Business Objects देखें।