क्या मुझे ASP.NET में प्रमाणित उपयोगकर्ताओं को संदर्भित करने के लिए उपयोगकर्ता नाम या उपयोगकर्ता का आईडी उपयोग करना चाहिए

तो मेरी सरल सीखने की वेबसाइट में, मैं एएसपी.NET प्रमाणीकरण प्रणाली में निर्मित का उपयोग करता हूं।

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

  1. नई तालिका में, कुंजी को उपयोगकर्ता नाम (स्ट्रिंग) या उपयोगकर्ता आईडी होना चाहिए जो वह GUID दिखने वाला नंबर है जिसे वे asp_ tables में उपयोग करते हैं।
  2. यदि सबसे अच्छा अभ्यास उस बदसूरत गाइड का उपयोग करना है, तो क्या कोई इसे जानता है कि इसे कैसे प्राप्त किया जाए? ऐसा लगता है कि नाम के रूप में आसानी से पहुंचा जा सकता है ( System.Web.HttpContext.Current.User.Identity.Name )
  3. यदि आप सुझाव देते हैं कि मैं न तो उपयोग करता हूं (GUID नहीं और न ही उपयोगकर्ता नाम फ़ील्ड ASP.NET प्रमाणीकरण द्वारा प्रदान किया गया है) तो मैं इसे ASP.NET प्रमाणीकरण के साथ कैसे करूं? मुझे पसंद है कि एक विकल्प उपयोगकर्ता के ईमेल पते का उपयोग लॉगिन के रूप में करना है, लेकिन मैं एएसपी.NET प्रमाणीकरण प्रणाली को उपयोगकर्ता नाम के बजाय ईमेल पता का उपयोग कैसे करूं? (या वहां करने के लिए कुछ भी नहीं है, यह सिर्फ मुझे तय है कि मैं "पता" उपयोगकर्ता नाम वास्तव में एक ईमेल पता है?

कृपया ध्यान दें:

  • मैं यह नहीं पूछ रहा हूं कि .NET में GUID कैसे प्राप्त करें, मैं केवल user code कॉलम को asp_ tables में guid के रूप में संदर्भित कर रहा हूं।
  • उपयोगकर्ता नाम ASP.NET प्रमाणीकरण में अद्वितीय है।
0
जोड़ा संपादित
विचारों: 91
स्रोत

12 उत्तर

मैं माइक स्टोन से सहमत हूं। मैं उस घटना में केवल एक GUID का उपयोग करने का सुझाव दूंगा जिसमें आप बहुत अधिक डेटा ट्रैक कर रहे हैं। अन्यथा, एक साधारण ऑटो incrementing पूर्णांक (आईडी) कॉलम पर्याप्त होगा।

यदि आपको GUID की आवश्यकता है, तो .NET इतना प्यारा है कि आप एक साधारण द्वारा प्राप्त कर सकते हैं ...

Dim guidProduct As Guid = Guid.NewGuid()

या

Guid guidProduct = Guid.NewGuid();
0
जोड़ा
स्रोत

आपको कुछ अद्वितीय आईडी, या तो GUID का उल्लेख करना चाहिए या कुछ अन्य ऑटो जेनरेट की गई कुंजी का उपयोग करना चाहिए। हालांकि, यह संख्या उपयोगकर्ता को कभी दिखाई नहीं देनी चाहिए।

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

0
जोड़ा
स्रोत

यदि उपयोगकर्ता नाम अद्वितीय होने जा रहा है, तो मैं तालिका में प्राथमिक कुंजी के रूप में उपयोगकर्ता नाम का उपयोग करने का सुझाव दूंगा, ऐसा करने के कुछ अच्छे कारण हैं:

  1. प्राथमिक कुंजी क्लस्टर्ड इंडेक्स होगी और इस प्रकार उनके उपयोगकर्ता नाम के माध्यम से उपयोगकर्ताओं के विवरण की खोज बहुत तेज होगी।
  2. यह डुप्लिकेट उपयोगकर्ता नामों को प्रकट होने से रोक देगा
  3. आपको जानकारी के दो अलग-अलग peices (उपयोगकर्ता नाम या guid) का उपयोग करने की चिंता करने की ज़रूरत नहीं है
  4. जानकारी के दो बिट्स को देखने के कारण यह लेखन कोड को अधिक आसान बना देगा।
0
जोड़ा
स्रोत
उपयोगकर्ता नाम का उपयोग करने में महत्वपूर्ण समस्या यह है कि यदि उपयोगकर्ता किसी कारण से अपना उपयोगकर्ता नाम बदलना चाहता है। यदि आप उपयोगकर्ता नाम का उपयोग करते हैं तो आपको केवल एक के बजाय कई तालिकाओं में परिवर्तन करना होगा। नोट: इस टिप्पणी को फिर नीचे पढ़ें और किसी और ने इसका उल्लेख किया।
जोड़ा लेखक percent20, स्रोत
अन्य संभावित समस्या तब उत्पन्न होती है जब उपयोगकर्ता नाम का समय के साथ पुन: उपयोग किया जा सकता है। उदाहरण के लिए, मान लीजिए कि आप अपने कस्टम प्राधिकरण मॉडल में उपयोगकर्ता नाम का उपयोग करते हैं। उपयोगकर्ता एएसमिथ को व्यवस्थापक के रूप में असाइन किया गया है। उसके बाद वह कंपनी छोड़ देता है और उसका उपयोगकर्ता रिकॉर्ड हटा दिया जाता है। एक नया उपयोगकर्ता कंपनी में शामिल होता है और उपयोगकर्ता नाम एस्मिथ असाइन किया जाता है। आपने संभावित रूप से उस उपयोगकर्ता व्यवस्थापक को इसे महसूस किए बिना पहुंच प्रदान की है।
जोड़ा लेखक Phil Haselden, स्रोत

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

मुझे यकीन नहीं है कि यह LinqToSql में एक ज्ञात बग है या क्या, लेकिन मुझे वर्तमान परियोजना पर इसके साथ समस्याएं थीं और मुझे कई तालिकाओं पर पीके और एफके को स्वैप करना पड़ा।

0
जोड़ा
स्रोत

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

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

0
जोड़ा
स्रोत

आपको उपयोगकर्ता आईडी का उपयोग करना चाहिए। यह सदस्यता यूज़र की ProviderUserKey संपत्ति है।

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
0
जोड़ा
स्रोत
Identity.Name के बाद आपके पास अतिरिक्त बंद कोष्ठक है
जोड़ा लेखक Marcel Popescu, स्रोत

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

0
जोड़ा
स्रोत

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

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

संपादित करें: यह वर्तमान एएसपी.Net सदस्यता तालिकाओं के साथ भी बेहतर होगा क्योंकि वे उपयोगकर्ता आईडी को प्राथमिक कुंजी के रूप में भी उपयोग करते हैं।

0
जोड़ा
स्रोत

मैं आमतौर पर एक int वृद्धिशील संख्या का उपयोग एक int।

आप जितनी छोटी हो सके कुंजी के आकार को रखना चाहते हैं। यह आपकी अनुक्रमणिका को छोटा रखता है और किसी भी विदेशी कुंजी को भी लाभ देता है। Additonally आप बाहरी उपयोगकर्ता डेटा के लिए डेटा डिजाइन कसकर जोड़ नहीं रहे हैं (यह एस्पनेट GUID के लिए भी सच है)।

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

0
जोड़ा
स्रोत

मैं पाल्मे से सहमत हूं, हालांकि उनके कोड में थोड़ी सी त्रुटि होती है:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

होना चाहिए

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
0
जोड़ा
स्रोत

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

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

0
जोड़ा
स्रोत

यह पुराना है, लेकिन मैं सिर्फ उन लोगों को चाहता हूं जो कुछ चीजों को ध्यान में रखते हैं:

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

  2. guid userid int से बड़ा सूचकांक आकार देगा लेकिन यह वास्तव में महत्वपूर्ण नहीं है क्योंकि हम अक्सर एक समय में केवल 1 रिकॉर्ड (उपयोगकर्ता) को पुनर्प्राप्त करते हैं और विखंडन के मामले में, आमतौर पर पढ़ने की संख्या बहुत अधिक होती है उपयोगकर्ता तालिका में लिखने और संपादन की संख्या - लोग बस उस जानकारी को अक्सर अपडेट नहीं करते हैं।

  3. regsql स्क्रिप्ट जो एस्पनेट सदस्यता तालिका बनाता है संपादित किया जा सकता है ताकि उपयोगकर्ता आईडी के लिए डिफ़ॉल्ट के रूप में NEWID का उपयोग करने के बजाय, यह NEWSEQUENTIALID() का उपयोग कर सकता है जो बेहतर प्रदर्शन प्रदान करता है (मैंने इसे प्रोफाइल किया है)।

  4. प्रोफ़ाइल। कोई "नई शिक्षा वेबसाइट" बनाने वाला व्यक्ति पहिया को फिर से शुरू करने की कोशिश नहीं करना चाहिए। वेबसाइटों में से एक मैंने एस्पनेट सदस्यता तालिकाओं के बॉक्स संस्करण (भयानक प्रोफ़ाइल सिस्टम को छोड़कर) के उपयोग के लिए काम किया है और उपयोगकर्ता तालिका में लगभग 2 मिलियन उपयोगकर्ता रिकॉर्ड हैं। यहां तक ​​कि रिकॉर्ड की इतनी बड़ी संख्या के साथ, चयन अभी भी तेज़ थे क्योंकि, जैसा कि मैंने शुरू करने के लिए कहा था, डेटाबेस इंडेक्स कमर्डसनाम + एप्लिकेशनिड पर फोकस क्लस्टर इंडेक्स पर ध्यान केंद्रित करने के लिए इन रिकॉर्ड्स की तलाश करते हैं और आम तौर पर बोलते हैं, अगर एसक्यूएल क्लस्टर्ड इंडेक्स की तलाश कर रहा है 1 रिकॉर्ड खोजने के लिए, आपको बड़ी संख्या में रिकॉर्ड्स के साथ कोई समस्या नहीं है, बशर्ते कि आप टेबल पर कॉलम न जोड़ें और बहुत अधिक डेटा वापस खींचना शुरू करें।

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

0
जोड़ा
स्रोत