2009-02-24 14 views
5

में एक कस्टम लॉगऑन/प्रमाणीकरण प्रणाली विकसित करने का सबसे अच्छा तरीका क्या है जो वेबसाइट मैं विकसित कर रहा हूं, वह उपयोगकर्ताओं को 3 स्तरों पर लॉगिन करने की अनुमति देगी।एएसपी.नेट

स्तर 1 - नहीं में

स्तर 2 लॉग इन किया - वे अपने ईमेल पते रजिस्टर और एक पुष्टिकरण ईमेल प्राप्त है, और के लिए लॉग इन कि जिस तरह से।

स्तर 2 - वे उपयोगकर्ता नाम/पासवर्ड के साथ लॉगिन करते हैं, जिसे तब एक वेब सेवा में भेजा जाता है। यदि वेब सेवा "सफल लॉगिन" परिणाम के साथ वापस आती है, तो वे वेबसाइट पर लॉग इन हैं।

लॉगिन स्तर के आधार पर, कुछ वेब पेज उपलब्ध होंगे जबकि अन्य प्रतिबंधित होंगे।

मेरा सवाल है, मुझे इसे कैसे विकसित करना चाहिए?

मैं एएसपी.नेट एमवीसी में प्रोजेक्ट कर रहा हूं।

क्या मुझे अपना खाता खाता नियंत्रक कोड करना चाहिए? क्या मुझे .NET फॉर्म प्रमाणीकरण का उपयोग करना चाहिए? फॉर्म प्रमाणीकरण का लाभ केवल मैन्युअल रूप से .NET कोड के साथ करने पर क्या है?

यदि मैंने इसे स्वयं लॉगिन किया है, तो सफल लॉगिन पर, मैं सिर्फ लॉग-इन उपयोगकर्ता को सत्र चर में संग्रहीत करता हूं। ऐसा करने में कोई हानि है, या जो मैं कर रहा हूं, क्या यह ठीक है?

+0

प्रमाणीकरण विधि आप क्या देख रहे हैं? – Suroot

+0

इस समय मैं अपने "खाता लॉग इन" विधि के साथ स्क्रैच से अपना खाता खाता नियंत्रक बनाने की सोच रहा हूं, जो पैरामीटर के रूप में "ईमेलड्रेस" स्वीकार करता है। यदि ईमेलड्रेस डीबी में है, तो यह उस डीबी रिकॉर्ड में सत्र चर "CurrentUser" सेट करता है। क्या ऐसा कोई कारण नहीं है? – Jonathan

उत्तर

1

मैं आपकी खुद की प्रमाणीकरण प्रणाली को रोल करने के खिलाफ दृढ़ता से अनुशंसा करता हूं। .NET फॉर्म ऑथ इतना आसान है; आप खुद को बनाने का समय बर्बाद क्यों करेंगे? प्रमाणीकरण प्रणालियों के लिए कई समस्याएं हैं और जब तक आप एमएस नहीं हैं, तो आपके पास वास्तव में संसाधन बनाने और परीक्षण करने के लिए संसाधन नहीं हैं।

यह निर्धारित करना कि उपयोगकर्ता कौन से पेज देख सकता है वह प्राधिकरण है और आप निश्चित रूप से अपना स्वयं का तरीका कोड कर सकते हैं। मैं पहचान/प्रिंसिपल इंटरफेस की तलाश करने का सुझाव दूंगा जो कि .NET में उपलब्ध हैं और आपकी जरूरतों को पूरा करने के लिए "IsInRole" विधि को ओवरराइड करते हैं।

सत्र सुरक्षा के लिए वास्तव में अच्छे नहीं हैं। वे वेब-फार्म परिदृश्यों में अच्छी तरह से काम नहीं करते हैं और जब ऐप पूल रीसायकल करने का निर्णय लेता है ... आपके सभी उपयोगकर्ता लॉग आउट हो जाते हैं। .net फॉर्म औथ डिफ़ॉल्ट रूप से कुकीज़ का उपयोग करता है।

+0

मेरा कहना है कि एएसपी.NET सदस्यता कैसे काम करती है, यह समझने की कोशिश करने से अपने सिस्टम को बाहर करना बहुत आसान है। इसके अलावा, मैं सचमुच सैकड़ों अनावश्यक टेबल नहीं चाहता हूं, मेरे डेटाबेस में रहने के लिए एएसपी.NET सदस्यता का समर्थन करने वाली प्रक्रियाओं को देख और संग्रहित करता हूं। – User

0

आपके मामले में, मैं सरल फॉर्म प्रमाणीकरण का उपयोग करने की अनुशंसा करता हूं। (How to: Implement Simple Forms Authentication देखें)। एक साधारण लॉगिन नियंत्रक इसे संभाल सकता है।

सत्र में उपयोगकर्ता प्रोफ़ाइल डेटा संग्रहीत करने के बारे में कुछ भी "गलत" नहीं है, लेकिन यदि आपको कभी भी अपनी वेबसाइट को संतुलित करने की आवश्यकता है तो इससे स्केलेबिलिटी समस्याएं हो सकती हैं। कस्टम रोलप्रोवाइडर को लागू करने के लिए अनुशंसित विधि है। (Implementing a Role Provider देखें।)

एक्सेस नियंत्रण के लिए, शायद आपके पास बेसकंट्रोलर क्लास हो सकती है जो उपयोगकर्ता की वर्तमान भूमिका को जांचने के लिए जांचती है कि उनके पास किस प्रकार की पहुंच है।

1

मैं सुझाव दूंगा कि अपना खुद का कस्टम सदस्यता/प्रमाणीकरण प्रणाली लिखने का सबसे अच्छा तरीका वास्तव में .NET में अंतर्निहित सदस्यता प्रदाता वर्ग का उपयोग करना है, और उस से अपनी खुद की कस्टम क्लास प्राप्त करना है।आप हमेशा System.Web.Security.MembershipProvider (और Role और Profile कक्षाओं) से विरासत में अपना स्वयं का सदस्यता प्रदाता बना सकते हैं।) .NET ढांचे के भीतर कक्षा, और अपना स्वयं का विशिष्ट कार्यान्वयन प्रदान करते हैं। इस तरह, आपको एक ठोस और भरोसेमंद "आधार ढांचा" का उपयोग करने का लाभ मिलता है जिस पर आपका प्रमाणीकरण और प्राधिकरण प्रणाली बनाना है।

ढांचे के स्वयं के आधार वर्ग द्वारा अपने कस्टम सदस्यता प्रदाता को प्राप्त करके, आप एएसपी.NET की सदस्यता प्रणाली की कई बेहतरीन सुविधाओं का लाभ उठाते हैं, जैसे वेब.कॉन्फिग फ़ाइल में घोषणात्मक प्राधिकरण और अंतर्निहित एएसपी.नेट प्रमाणीकरण टिकट। मैंने एक बहुत ही समान प्रश्न here का उत्तर दिया जो इनमें से कुछ लाभों का विवरण देता है।

मुझे स्वीकार करना होगा, एएसपी.नेट में "मानक" अंतर्निहित सदस्यता प्रदाताओं में इसे छोड़कर मुझे असामान्य लगता है, उपयोगकर्ताओं को वेबसाइट के साथ पंजीकरण करने की अनुमति देने का एक आसान तरीका था, लेकिन " "तुरंत उनके खाते को मान्य करें, बल्कि उपयोगकर्ता को" सत्यापन लिंक "वाला एक ईमेल भेजें, जिसे वेबसाइट पर पहुंच की अनुमति देने से पहले उन्हें क्लिक करना होगा। हालांकि यह एएसपी.NET सदस्यता प्रदाता वर्ग के भीतर एक मानक विशेषता नहीं है, यह लागू करने के लिए अपेक्षाकृत आसान है।

यहां पाया जा सकता है (प्रवेश अनुमति देने से पहले ईमेल के माध्यम से एक खाता सत्यापन के लिए एक सहित) ASP.NET के सदस्यता, भूमिका और प्रोफाइल प्रदाताओं के बारे में स्कॉट मिशेल द्वारा लेख की एक महान श्रृंखला है:

Examining ASP.NET 2.0's Membership, Roles, and Profile

जो आपको एएसपी.NET प्रदाताओं से अपना कस्टम प्रदाता प्राप्त करने में मदद करनी चाहिए।