एएसपी.नेट में सदस्यता, सदस्यताप्रदाता और सदस्यता उपयोगकर्ता संबंध?

Question

मैं उपयोगकर्ता नामक एक एमएसएसक्यूएल तालिका में उपयोगकर्ता डेटा संग्रहीत करता हूं। मैं वास्तव में लॉग इन उपयोगकर्ता (ईमेल, पता, फोन, यदि उपयोगकर्ता ग्राहक है) के लिए सभी उपयोगकर्ता के डेटा को एक्सेस करना चाहता हूं।

मैं प्रोफाइल का उपयोग नहीं करना चाहता इसलिए मैंने कस्टम सदस्यता प्रदाता का उपयोग करने का निर्णय लिया (या क्या आप कुछ बेहतर, कम दर्दनाक तरीके जानते हैं?)।

जो मुझे समझ में नहीं आता है सदस्यताकर्ता और सदस्यता है। यदि मैं सदस्यता प्रदाता से विरासत में हूं, तो ओवरराइड तरीकों से मैं डेटा से डेटाबेस तक पहुंच डेटा नियंत्रित करता हूं।

लेकिन मैं सदस्यता प्रदाता से विरासत कक्षा का उपयोग कैसे करूं? मैं सदस्यता का उपयोग करके उपयोगकर्ता को प्रमाणित करना चाहते हैं, मुझे क्या करना चाहिए:

if(Membership.ValidateUser(string username, string password)) 
{ 
    FormsAuthentication.RedirectFromLoginPage(string username, string password); 
} 

लेकिन जहां वर्ग MembershipProvider से विरासत में मिली है? और सदस्यता यूज़र से विरासत में प्राप्त कक्षा का उपयोग कब करें? और सदस्यता और सदस्यता प्रदाता के बीच संबंध क्या है?

Answer 1

हालांकि यह क्रिस्टल स्पष्ट on MSDN नहीं है, यह सब जटिल नहीं है। कक्षाओं का एक तिहाई है:

• सदस्यता: उपयोगिता विधियों और प्रविष्टि का एक बिंदु प्रदान करता है - मूल रूप से सिंगलटन (स्थैतिक वर्ग)।
• सदस्यताप्रदाता: सदस्यता यूज़र ऑब्जेक्ट्स के लिए डेटा एक्सेसर और फैक्ट्री के रूप में कार्य करता है।
• सदस्यता उपयोगकर्ता: एक व्यक्तिगत उपयोगकर्ता का प्रतिनिधित्व करता है।

आपके आवेदन की कॉन्फ़िगरेशन के आधार पर एक कस्टम सदस्यता प्रदाता (सदस्यता में कोड द्वारा) चुना गया है: कॉन्फ़िगरेशन/system.web/सदस्यता। यहां वह जगह है जहां आप अपना प्रदाता खेल में लाते हैं। आपके सदस्यता प्रदाता कार्यान्वयन को उपयोगकर्ताओं के लिए जो भी डेटा स्टोर पसंद है, उसे एक्सेस करने के लिए लिखा जाना चाहिए: इस मामले में आपकी उपयोगकर्ता तालिका।

सदस्यता यूज़र ऑब्जेक्ट केवल आपके सदस्यता प्रदाता के माध्यम से बनाए जाते हैं। सदस्यता प्रदाता। ValidateUser() विधि को आपके डेटा स्टोर के विरुद्ध जांच करनी चाहिए कि उपयोगकर्ता/पासवर्ड संयोजन मान्य है। सदस्यताप्रदाता.गेट यूज़र() उपयोगकर्ता की जानकारी पुनर्प्राप्त करता है - इसे किसी एक्सेस संरक्षित पृष्ठ के भीतर उपयोग करें और सिस्टम प्रमाणीकृत उपयोगकर्ता के रूप में System.Web.HttpContext.Current.User.Identity.Name में पास करें।

यह कहा गया, मुझे आशा है कि आप सुनिश्चित हैं कि आप use Profiles नहीं चाहते हैं, और वास्तव में एक अलग उपयोगकर्ता तालिका चाहते हैं। यदि आप मौजूदा Active Directory या LDAP का उपयोग कर आंतरिक एप्लिकेशन लिख रहे हैं, तो सक्षम डेटा स्टोर प्रशासन लागत और शायद सुरक्षा जोखिम को कम करेगा। सदस्यता प्रदाता मार्ग पर जाने पर सैकड़ों चीजें आप आसानी से गलत कर सकते हैं। क्या आप salted hashes का उपयोग करते हैं? आप मैनिपुलेशन के खिलाफ उपयोगकर्ता तालिका की रक्षा कैसे कर रहे हैं? एमएसडीएन में security issues का केवल एक अंश शामिल है जिसका आप सामना कर सकते हैं।

Answer 2

प्रयुक्त विशिष्ट प्रदाता web.config पर नियंत्रित होता है। आप वास्तव में 1 से अधिक प्रदाता सेट कर सकते हैं, और एक डिफ़ॉल्ट है। जांचें: http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx।

जब ऐसा कहा जाता है, तो सदस्यता केवल डिफ़ॉल्ट प्रदाता का उपयोग करती है। यदि आप उपयोगकर्ता के लिए अतिरिक्त जानकारी प्रदान करना चाहते हैं, तो आप सदस्यता यूज़र का उत्तराधिकारी होंगे, लेकिन यह आपके शेष प्रदाता को आपके विशिष्ट प्रदाता को जोड़ देगा।