6

मेरे पास एक ऐसी साइट है जिसमें एक ऐसा क्षेत्र है जिसके लिए प्रमाणीकरण की आवश्यकता है। अभी मैं उस क्षेत्र के सभी नियंत्रकों पर भूमिका विशेषता का उपयोग करता हूं, और मैं उस उपयोगकर्ता आईडी और उनकी सभी सेटिंग्स को पुनर्प्राप्त करने के लिए एक क्वेरी चलाता हूं।मुझे एएसपी.NET एमवीसी साइट में प्रमाणीकरण कैसे करना चाहिए?

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

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

+2

अपने शीर्षक को वर्णनात्मक बनाने का एक अच्छा विचार है। यह शीर्षक स्पष्ट रूप से बेकार है। मैं कुछ ऐसा उपयोग करूंगा जैसे "मुझे ASP.Net साइट में प्रमाणीकरण कैसे करना चाहिए?" –

+0

आपके प्रश्न की तरह लगता है मुख्य रूप से प्रदर्शन के बारे में है? आपको लगता है कि आप सेटिंग्स डेटाबेस को अक्सर मार रहे हैं? –

+0

मुझे लगता है कि यह सत्रों का उपयोग किए बिना स्थायी डेटा के लिए एक सरल एमवीसी (1 या 2) विशिष्ट समाधान है। – chobo

उत्तर

11

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

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

अंतिम विकल्प कस्टम सदस्यता प्रदाता वर्ग लिखना होगा। हालांकि यह अभी भी अपना खुद का रोलिंग कर रहा है, यह आपको सदस्यता प्रदाता की संरचना में मजबूर करता है ताकि आप बाद में किसी दूसरे (जैसे ActiveDirectoryMembershipProvider) के लिए इसे स्वैप कर सकें और प्रमाण-पत्र और लॉगिन के साथ बातचीत करने के लिए एक सामान्य इंटरफ़ेस प्रदान कर सकें जो उदाहरण के लिए अंतर्निहित लॉगिन नियंत्रण के आसान उपयोग को सक्षम बनाता है।

यदि आप पहले से ही सदस्यता प्रदाता का उपयोग कर रहे हैं और अतिरिक्त उपयोगकर्ता-विशिष्ट डेटा संग्रहीत करने के बारे में पूछ रहे हैं, तो मैं SqlMrbershipProvider के बारे में ऊपर बताई गई सभी चेतावनियों के साथ SqlProfileProvider का सुझाव दूंगा। प्रोफाइलप्रोवाइडर वर्तमान में लॉग ऑन उपयोगकर्ता के साथ उपयोगकर्ता-विशिष्ट डेटा को बनाए रखने के लिए एक संरचना प्रदान करता है।

अधिक जानकारी के लिए:

+0

मैं वर्तमान में एक कस्टम सदस्यता प्रदाता का उपयोग कर रहा हूं जो अच्छी तरह से काम करता है। मैं यह समझने की कोशिश कर रहा हूं कि उपयोगकर्ता आईडी और सेटिंग्स को संभालने का सबसे अच्छा तरीका क्या होगा। जब मैं क्षेत्र में लॉग इन करता हूं तो मैं केवल उपयोगकर्ता आईडी और सेटिंग्स को पुनर्प्राप्त करना चाहता हूं। मुझे यकीन नहीं है कि उस क्षेत्र में ओटेर नियंत्रकों में उस डेटा को बनाए रखने के लिए सबसे अच्छा तरीका कौन सा होगा। खाता प्रदर्शन और सुरक्षा भी लेना। – chobo

+0

@chobo - यदि आप एक कस्टम सदस्यता प्रदाता का उपयोग कर रहे हैं, तो आप उपयोगकर्ता सदस्यता प्राप्त करने के लिए GetUser से लौटाए गए 'सदस्यता उपयोगकर्ता' वर्ग पर 'ProviderUserKey' प्रॉपर्टी का उपयोग करने में सक्षम होना चाहिए। उपयोगकर्ता सेटिंग्स के लिए, मैं एक प्रोफाइलप्रोवाइडर को लागू करने के लिए सुझाव देना चाहता हूं। – Thomas

+0

@chobo: मैं प्रोफाइलप्रोवाइडर का उपयोग करने की सिफारिश नहीं करता हूं, यह एक ओवरहेड है जिसकी आपको आवश्यकता नहीं है और जिस तरह से इसे बॉक्स में लागू किया गया है वह भयानक है।उपयोगकर्ता तालिका (या संबंधित तालिका) में सेटिंग्स और प्राथमिकताओं को जोड़ने के लिए यह बहुत आसान है और सत्र में सहेजी गई एक छोटी डीटीओ/व्यूडाटा ऑब्जेक्ट बनाएं जो अक्सर आपके द्वारा उपयोग की जाने वाली जानकारी (प्रमाणीकरण जानकारी नहीं) रखती है जिसे आपके सदस्यता प्रदाता द्वारा प्रबंधित किया जाता है। –

0

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

+0

मैं सत्रों का उपयोग करने के बारे में बाड़ पर हूं। कुछ लोग कहते हैं कि आपको कभी उनका उपयोग नहीं करना चाहिए और दूसरों का कहना है कि वे उपयोग करना ठीक है। – chobo

+0

यदि आप प्रत्येक उपयोगकर्ता के लिए उपयोग की जाने वाली संग्रहण की मात्रा के बारे में सावधान हैं तो इसे ठीक करना चाहिए। कुकीज़ एक विकल्प हैं, लेकिन मैं वेब/मोबाइल ब्राउज़र प्रतिबंधों का पता लगाऊंगा। –

1

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

जेनेरिक इडेंटिटी से विरासत में प्राप्त एक नई कक्षा बनाएं, और आप अपने रास्ते पर होंगे।

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

हम उपयोगकर्ता के बारे में जानकारी के कुछ बिट्स स्टोर करने के लिए एक कस्टम पहचान का उपयोग करते हैं, और यह बहुत अच्छी तरह से काम करता है।

+0

मुझे लगता है कि जानकारी सेट करने के लिए कुकी एक अच्छी पसंद हो सकती है। – chobo

0

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

एक बार लॉग ऑन होने पर, उपयोगकर्ता के दावों को HttpContext.Current.User फ़ील्ड से पढ़ा जा सकता है। आप "रोल" दावों का भी उपयोग कर सकते हैं जो एक भूमिका-आधारित प्रमाणीकरण स्कीमा के साथ सहजता से एकीकृत होते हैं; जिसका अर्थ है कि आप उपयोगकर्ता को "प्रबंधक" भूमिका दावा दे सकते हैं और फिर 'if (User.IsInRole ("manager") का उपयोग कर सकते हैं।

एक अतिरिक्त बोनस के रूप में, डब्ल्यूआईएफ अन्य अनुप्रयोगों में अपनी लॉगिन स्क्रीन का पुन: उपयोग करना बहुत आसान बनाता है।

सब कुछ, यह बहुत लचीला है, लेकिन दस्तावेज़ीकरण बहुत खराब है। मैंने StackOverflow पर "विंडोज आइडेंटिटी फाउंडेशन" के बारे में कई प्रश्न पूछे और जवाब दिए हैं।

0

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

यदि आप SQL सर्वर का उपयोग कर रहे हैं, तो माइक्रोसॉफ्ट ने इसके लिए 2.0 कोड जारी किया है। आप स्कॉट गु के ब्लॉग पर अधिक जानकारी प्राप्त कर सकते हैं।

http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx

आप स्क्रैच से शुरू करने के लिए चाहते हैं, वे भी अच्छे संसाधन MSDN पर है।

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

और

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

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

स्रोत कोड के 2.0 संस्करण की माइक्रोसॉफ्ट रिलीज के साथ, हमने पाया कि इससे हमें कुछ चिंताओं को कम करने में मदद मिली जो कि पुनर्विचार के बारे में मौजूद हैं। आपके कार्यान्वयन के लिए विचार करने की एक और बात आपके परिदृश्य पर आधारित है, आप कुछ कोड लागू करने को बाईपास कर सकते हैं। इसका एक उदाहरण CreateUser कोड होगा यदि आप बैक एंड सिस्टम को मार रहे हैं जिसमें पहले से ही क्रेडेंशियल जानकारी है।

0

ऐसा लगता है कि आप अपनी प्रमाणीकरण प्रक्रिया से अपेक्षाकृत खुश हैं लेकिन आप सत्र/सेटिंग्स के लिए अन्य विकल्पों का पता लगाना चाहते हैं।

मेरा सुझाव केवल सेटिंग्स (भूमिकाएं, वरीयताओं आदि) के साथ करना है।)

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

आप एक सत्र प्रणाली पर विचार कर सकते हैं जो भारी आरडीबीएमएस सिस्टम या एएसपी.नेट कैशिंग/सत्र मॉडल पर निर्भर नहीं है। ऐसे विकल्प हैं जो बहुत ही कुशल हैं और यह स्केल अच्छी तरह से हैं।

आप Ayende Rahien (.NET के लिए निर्मित) द्वारा RavenDB का उपयोग कर सकते हैं। इसका मुख्य लक्ष्य कम विलंबता, स्कीमा-कम JSON दस्तावेज़ों तक उच्च प्रदर्शन पहुंच प्रदान करना है।

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

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

विचार करने के लिए लाखों विकल्पों में से एक और।

गुड लक,

हमें बताएं कि आप क्या निर्णय लेते हैं!

पैट्रिक।

+0

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

संबंधित मुद्दे