एएसपी.NET कस्टम सदस्यता प्रदाता

Question

मुझे एक बहुत बड़ी वेबसाइट के लिए सदस्यता समाधान के साथ आना होगा। साइट एएसपी.नेट एमवीसी 2 और एक एमएस एसक्यूएल 2008 डेटाबेस का उपयोग करके बनाई जाएगी।

वर्तमान सदस्यता प्रदाता एक बड़ी ओवरकिल की तरह लगता है, वहां बहुत अधिक कार्यक्षमता है।

मैं स्टोर करना चाहता हूं ईमेल/पासवर्ड और मूल प्रोफ़ाइल जानकारी जैसे फर्स्ट/लास्टनाम, फोन नंबर। मुझे केवल 2 भूमिकाओं, प्रशासकों & उपयोगकर्ताओं की आवश्यकता होगी।

इस प्रकार के परिदृश्य पर आपकी क्या सिफारिशें हैं, इस पर विचार करते हुए कि लाखों उपयोगकर्ता पंजीकृत हो सकते हैं? StackOverflow का उपयोग क्या करता है?

मैं मौजूदा सदस्यता एपीआई अतीत में एक बहुत उपयोग किया है और अतिरिक्त जानकारी के आदि स्टोर करने के लिए यह विस्तार किया है लेकिन वहाँ

aspnet_Applications 
aspnet_Paths 
aspnet_SchemaVersions 
aspnet_WebEvent_Events 
aspnet_PersonalizationAllUsers 
aspnet_PersonalizationPerUser 

जो बहुत ही निरर्थक हैं जैसे टेबल है और मैं उपयोग कभी नहीं मिला है के लिये।

संपादित
बस कुछ अन्य अतिरिक्तताओं @ drachenstern के जवाब के बाद, वहाँ भी कर रहे हैं अतिरिक्त कॉलम जो मैं सदस्यता/उपयोगकर्ता तालिका में के लिए किसी काम का नहीं है स्पष्ट करने के लिए है, लेकिन जो प्रत्येक चयन के पेलोड को जोड़ना होगा/बयान सम्मिलित करें।

1. MobilePIN
2. PasswordQuestion/PasswordAnswer (मैं ईमेल आधारित पासवर्ड वसूली करते होगी)
3. IsApproved (उपयोगकर्ता हमेशा मंजूरी दे दी जाएगी)
4. टिप्पणी
5. MobileAlias ​​
6. प्रयोक्ता नाम/LoweredUsername (या ईमेल/LoweredEmail) [ईमेल उपयोगकर्ता नाम है इनमें से केवल 1]

इसके अलावा जरूरत है, मैंने सुना है कि GUID के सभी कि तेजी से नहीं कर रहे हैं, और बदले में पूर्णांक के लिए (फेसबुक की तरह) पसंद करेंगे जो भी सार्वजनिक रूप से उजागर किया जाएगा।

मैं कैसे बनाने के बारे में जाना कर अपने ही सदस्यता प्रदाता, पुनः उपयोग (, सत्यापन, पासवर्ड एन्क्रिप्शन, लॉगिन कुकी आदि) सदस्यता एपीआई के कुछ लेकिन केवल तालिकाओं कि मेरे आवश्यकताओं को पूरा के साथ?

लेखों और मौजूदा कार्यान्वयन के लिए लिंक का स्वागत है, मेरी Google खोजों ने कुछ बहुत ही बुनियादी उदाहरण वापस कर दिए हैं।

अग्रिम धन्यवाद
मार्को

Answer 1

@Marko मैं निश्चित रूप से समझ सकते हैं कि मानक सदस्यता प्रणाली अधिक कार्यक्षमता हो सकती है की तुलना में आप की जरूरत है, लेकिन सच्चाई यह है कि यह वास्तव में कोई फर्क नहीं जा रहा है। सदस्यता प्रणाली के कुछ हिस्सों हैं जिनका उपयोग आप नहीं करेंगे जैसे कि नेट के कुछ हिस्सों हैं जिनका उपयोग आप नहीं करेंगे। ऐसी कई चीजें हैं जो नेट कर सकते हैं कि आप कभी भी उपयोग नहीं करेंगे, लेकिन आप जा रहे हैं। नेट और उस कार्यक्षमता को बाहर निकालना आप हैं? बिलकूल नही। आपको उन चीजों पर ध्यान देना होगा जो आप पूरा करने और वहां से काम करने की कोशिश कर रहे हैं। विश्लेषण के पक्षाघात में पकड़े मत जाओ। आप अपना समय बर्बाद कर देंगे, अपने पहियों को स्पिन करेंगे और आपके लिए पहले से ही जो कुछ भी बनाया गया है उससे बेहतर कुछ भी खत्म नहीं होगा। अब माइक्रोसॉफ्ट को कभी-कभी यह गलत लगता है, लेकिन उन्हें बहुत सारी चीज़ें मिलती हैं। आपको अपने लक्ष्यों को पूरा करने के लिए जो कुछ भी करना है उसे गले लगाने की ज़रूरत नहीं है - आपको बस समझना होगा कि आपकी ज़रूरतों के लिए क्या महत्वपूर्ण है।

GUIDs और प्राथमिक कुंजी के रूप में ints के लिए

के रूप में, मुझे कुछ स्पष्ट करता हूं। प्राथमिक कुंजी और क्लस्टर्ड इंडेक्स के बीच एक महत्वपूर्ण अंतर है। आप प्राथमिक कुंजी और क्लस्टर किए गए इंडेक्स को कॉलम पर जोड़ सकते हैं जो प्राथमिक कुंजी का हिस्सा नहीं हैं! इसका अर्थ यह है कि यदि आपके डेटा को किसी नाम (या जो कुछ भी) द्वारा व्यवस्थित करना महत्वपूर्ण है, तो आप अपनी क्लस्टर इंडेक्स को कस्टमाइज़ कर सकते हैं ताकि आप अपनी प्राथमिक कुंजी को प्रभावित किए बिना बिल्कुल वही चीज़ों को प्रतिबिंबित कर सकें। मुझे इसे एक और तरीका कहना है - एक प्राथमिक कुंजी और क्लस्टर्ड इंडेक्स एक ही नहीं है। मैंने क्लस्टर इंडेक्स को जोड़ने और फिर अपनी टेबल पर प्राथमिक कुंजी जोड़ने के बारे में एक ब्लॉग पोस्ट लिखा था। क्लस्टरर्ड इंडेक्स भौतिक रूप से तालिका पंक्तियों को जिस तरह से आपको चाहिए, उसे प्राथमिक रूप से ऑर्डर करेगा और प्राथमिक कुंजी आपको आवश्यक अखंडता को लागू करेगी। यह देखने के लिए कि आप इसे कैसे कर सकते हैं, मेरे ब्लॉग पोस्ट पर एक नज़र डालें। http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html -

यहाँ की कड़ी है।

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

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

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

आपको शुभकामनाएँ!

Answer 2

वर्तमान सदस्यता प्रदाता एक बड़ी overkill की तरह लगता है, वहाँ बहुत ज़्यादा सुविधा है।

मैं स्टोर करना चाहता हूं ईमेल/पासवर्ड और मूल प्रोफ़ाइल जानकारी जैसे फर्स्ट/लास्टनाम, फोन नंबर। मुझे केवल 2 भूमिकाओं, प्रशासकों & उपयोगकर्ताओं की आवश्यकता होगी।

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

डेटाबेस का आकार काफी छोटा है, और यदि आप ऐसा करते हैं, और एस्पनेट डीबी को छोड़ दें, तो आप वास्तव में अपने अन्य डेटाबेस से कुछ भी नहीं ले रहे हैं।

क्या आपके पास पहले से ही ढांचे में क्या है, किसी तीसरे पक्ष के घटक का उपयोग करने के लिए एक अनिवार्य कारण है?

---

संपादित:

वहां भी अतिरिक्त कॉलम जो मैं में सदस्यता/उपयोगकर्ता तालिका के लिए कोई फायदा नहीं है, लेकिन जो के पेलोड को जोड़ना होगा प्रत्येक चयन/बयान सम्मिलित करें।

MobilePIN PasswordQuestion/PasswordAnswer (मैं ईमेल आधारित पासवर्ड रिकवरी करूँगा) IsApproved (उपयोगकर्ता हमेशा जा मंजूरी दे दी जाएगी) टिप्पणी MobileAlias ​​ उपयोगकर्ता नाम/LoweredUsername (या ईमेल/LoweredEmail) [ईमेल उपयोगकर्ता नाम है इसलिए केवल इनमें से 1 की आवश्यकता है]

ऐसा लगता है कि आप microoptimize पर प्रयास कर रहे हैं। खाली तारों को पास करना लगभग बिना लागत के है (ठीक है, यह वहां है, लेकिन आपको यह जानने के लिए प्रोफाइल करना होगा कि यह कितना खर्च कर रहा है। यह प्रति उपयोगकर्ता जितना अधिक नहीं होगा)। हम पहले से ही नियमित रूप से इन सभी क्षेत्रों को हमारे ऐप्स में उपयोग नहीं करते हैं, लेकिन हम सदस्यता प्रणाली का उपयोग किसी मापनीय हानिकारक प्रभाव के साथ नहीं करते हैं।

इसके अलावा, मैंने सुना है कि गइड सभी तेज़ नहीं हैं, और इसके बजाय पूर्णांक (फेसबुक की तरह) होना पसंद करेंगे जो सार्वजनिक रूप से सामने आएंगे।

मैंने सुना है कि cookiemonster कुकीज़ पसंद करता है। फिर, प्रोफाइलिंग के बिना, आप नहीं जानते कि यह हानिकारक है या नहीं। आम तौर पर लोग GUID का उपयोग करते हैं क्योंकि वे इसे पूरी तरह से (पूर्णता की डिग्री के लिए) अद्वितीय होना चाहते हैं, इससे कोई फर्क नहीं पड़ता कि यह कब बनाया गया है। प्रति उपयोगकर्ता एक बार उत्पन्न करने की लागत वह सब भारी नहीं है। जब आप पहले से ही उन्हें एक नया खाता बना रहे हैं।

---

आप पूरी तरह शुरू से एक MembershipProvider बनाने पर सेट कर रहे हैं के बाद से, यहाँ कुछ संदर्भों हैं:

http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx

http://www.4guysfromrolla.com/articles/120705-1.aspx

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113

स्टीफन वाल्थर अपनी पुस्तक में उस पर विस्तार से आगे बढ़ते हैं और यह आपके लिए एक अच्छा संदर्भ है।

Answer 3

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

मेरा अनुमान है कि यह ठीक हो जाएगा है, भूमि के ऊपर है कि आप के बारे में बात कर रहे हैं नगण्य होगा।