एएसपी.नेट

Question

सारांश में डेटा-आधारित प्रमाणीकरण: मुझे केवल यूआरएल की क्वेरी स्ट्रिंग में मौजूद डेटा के आधार पर पृष्ठों को अधिकृत करने की आवश्यकता है, न केवल पृष्ठ का नाम।

---

पृष्ठभूमि:

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

अभी मैं एक सुंदर मानक एएसपी.NET सेटअप का उपयोग कर रहा हूं: SqlMembershipProvider का उपयोग कर प्रपत्र प्रमाणीकरण। Web.config में <authorization> अनुभागों के माध्यम से कॉन्फ़िगर किया गया SqlRoleProvider का उपयोग कर प्राधिकरण। अनधिकृत पृष्ठों को छिपाने के लिए साइटमैप प्रदाता के साथ सुरक्षा ट्रिमिंग।

लीकिंग से सूची जानकारी को नियंत्रित करने के लिए, मैं मैन्युअल रूप से प्रत्येक इन्वेंट्री क्वेरी के साथ उपयोगकर्ता की सहयोगी लाइब्रेरी आईडी की जांच कर रहा हूं। यह काम करता है, लेकिन यह कठिन है और त्रुटियों के लिए प्रवण है। कोई बेहतर तरीका ज़रूर होगा।

प्रश्न:

अब उपयोगकर्ताओं को एक पुस्तकालय के भीतर मनमाना "संग्रह" बनाने की क्षमता है। (उदाहरण के लिए संग्रह ए में पुस्तकें 1, 2, & 3 है।) व्यवस्थापक केवल संपूर्ण पुस्तकालय में नहीं, व्यक्तिगत संग्रह पर व्यवस्थापक/उपयोगकर्ता पहुंच प्रदान करने की क्षमता चाहते हैं।

तो, यदि कोई उपयोगकर्ता www.com/Book.aspx?BookId=1 पर जाता है, तो सिस्टम को यह सुनिश्चित करने की आवश्यकता होती है कि उपयोगकर्ता को संग्रह के लिए अनुमति है कि "पुस्तक 1" पृष्ठ दिखाने से पहले है। अगर वे www.com/Reviews.aspx?ReviewId=23 पर जाते हैं, तो मुझे यह सुनिश्चित करना होगा कि समीक्षा उस पुस्तक के लिए है जो उस संग्रह में है जिसे उन्हें देखने की अनुमति है।

1) मैं इसे सबसे मानक एएसपी.NET तरीके से कैसे कार्यान्वित कर सकता हूं?
आधार पृष्ठ के भीतर मैन्युअल जांच?
एक कस्टम HttpModule?
एक कस्टम भूमिका प्रदाता?
मुझे व्यवस्थापक/उपयोगकर्ता अनुमतियों को संग्रहीत करने में रुचि नहीं है, बल्कि उन अनुमतियों के आधार पर अधिकृत/कैसे प्राधिकृत करें। (कैसे उन में से किसी को लागू करने पर उदाहरण की सराहना कर रहे हैं)

2) आगे यह जटिल करने के लिए, मैं अभी भी था सुरक्षा करता है, तो उपयोगकर्ता किसी भी संग्रह या लाइब्रेरी व्यवस्थापक अधिकार है की जाँच करें और व्यवस्थापक को छिपाने के लिए ट्रिमिंग की तरह पेज अगर वह नहीं करता है।

Answer 1

मैं इसे यूआई (एएसपी.नेट) परत के पास कहीं भी नहीं बल्कि एप्लिकेशन सेवाओं के भीतर संभाल नहीं सकता।

1. सेवाओं बिल्ड जो एक IPrincipal (या अपने कस्टम उपयोगकर्ता ऑब्जेक्ट) एक निर्माता पैरामीटर के रूप में लेते हैं: की तरह।
2. किसी पुस्तक/समीक्षा/जो भी अनुरोध करते हैं, सेवा पर यह देखने के लिए जिम्मेदार है कि उपयोगकर्ता को संसाधन तक पहुंच है या नहीं।
3. यदि उपयोगकर्ता के पास पहुंच नहीं है, तो कुछ पूर्व निर्धारित चीजें करें ( संदेश पास करें, एक अपवाद फेंक दें, शून्य वापस करें)।

यह लंबे समय तक अधिक परीक्षण योग्य और प्रयोग योग्य होगा और इसके बाद एएसपी.नेट यूआई पक्ष से इसकी चिंता कर रहा है।

आप ASP.NET तरफ इसे संभाल करने के लिए है, तो मैं उपयोग करने के लिए एक भूमिका के रूप में प्रत्येक पुस्तकालय लपेट के लिए एक कस्टम IPrincipal और कस्टम RoleProvider उपयोग करने पर विचार करना चाहते हैं, तो आप LoginView, आदि के सबसे इस्तेमाल कर सकते हैं नियंत्रित करता है।

Answer 2

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

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

उदाहरण, मानते हैं कि उपयोगकर्ता केवल एक पुस्तकालय से संबंधित हो सकता है।

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

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