.NET कस्टम सदस्यता बनाम। कस्टम लॉगिन/पंजीकरण: प्रमाणीकरण/प्रमाणीकरण

Question

जब मैं ऐसी साइट बनाता हूं जिसके लिए पंजीकरण और लॉगिन की आवश्यकता होती है, तो बहुत सारी आवश्यकताओं के बिना कुछ जल्दी के लिए मैं सदस्यता [प्राधिकरण] विशेषताओं और क्या नहीं के साथ सदस्यता का उपयोग करूंगा। यह क्या करता है इसके लिए अच्छा काम करता है। लेकिन अब मैं कुछ और चाहता हूँ। असल में मैं एएसपी.नेट एमवीसी ईएफ कोड फर्स्ट का उपयोग कर एक साइट विकसित कर रहा हूं और डीबी को जारी रखने के लिए एक उपयोगकर्ता इकाई बनाना चाहता हूं जिसमें अधिक जानकारी हो। पंजीकरण करते समय ऐसी जानकारी की आवश्यकता होती है जैसे फर्स्टनाम, लास्टनाम, लिंग, देश इत्यादि ...

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

करने के लिए यह ठीक है? मुझे समझ में नहीं आता कि यह पूरी सदस्यता चीज इतनी जटिल क्यों है कि ऐसा लगता है कि ऐसा लगता है कि मुझे लगता है कि मैं इसका सब कुछ याद कर रहा हूं। इसके अलावा, मैं एक ASP.NET MVC वेब एप्लिकेशन आपको कर रहे हैं जब प्रमाणीकृत है कि यह इस लाइन बाहर लिखते में नोटिस ....

FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false); 

कि और क्या अंतर है ...

Session["username"] = model.UserName 

Answer 1

सदस्यता प्रदाता के मार्ग पर जाने के बजाय (मैं व्यक्तिगत रूप से इसे पसंद नहीं करता हूं और जिन अनुप्रयोगों के साथ मैं काम करता हूं उनके लिए इसे बहुत अधिक भारी लगता है) क्या आपने अपने आवेदन के लिए कस्टम IPrinicipal/IIdentity ऑब्जेक्ट बनाने और उन्हें विस्तारित करने पर विचार किया है गुण जो आप अपने "उपयोगकर्ता" ऑब्जेक्ट से चाहते हैं? ASP.NET MVC - Set custom IIdentity or IPrincipal

अपने प्रश्न के संबंध में, Session["username"] बस एक सत्र कुकी है:

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

Session["username"] के साथ आपको प्रमाणीकरण के हर पहलू को मैन्युअल रूप से रोल करने की आवश्यकता होगी। मैं दृढ़ता से ऐसा करने की सलाह नहीं दूंगा।