कुकी प्रमाणीकरण विकल्प क्या है। प्रमाणीकरण टाइप के लिए उपयोग किया जाता है?

Question

अपने आवेदन के Asp.Net पहचान प्रमाणीकरण मिडलवेयर सेटअप में मेरे पास है

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
    LoginPath = new PathString("/Login/"), 
    //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    Provider = new CookieAuthenticationProvider { 
    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
         TimeSpan.FromMinutes(30), 
         (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie) 
        ), 
    }, 
}); 

मैं एक ऐप्लिकेशन से इस नकल की थी और मैं सिर्फ देखा है कि अगर मैं AuthenticationType लाइन uncomment, लॉगिन सफल होता है (मैं में एक सफलता संदेश मिलता है मेरी मेरे नियंत्रक से लिखा लॉगजर) लेकिन हमेशा लॉगिन स्क्रीन पर रीडायरेक्ट करता है।

documentation for CookieAuthenticationOptions में यह कहते हैं

AuthenticationType विकल्पों में IIdentity AuthenticationType संपत्ति से मेल खाती है। (AuthenticationOptions से विरासत।) एक अलग मूल्य के लिए एक पाइप लाइन में एक बार से अधिक एक ही प्रमाणीकरण मिडलवेयर प्रकार का उपयोग करने में सौंपा जा सकता है।

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

Answer 1

यह एक स्ट्रिंग है और कुछ भी हो सकता है। लेकिन यह प्रमाणीकरण प्रकार के लिए एक पहचानकर्ता है। और आपके पास एकाधिक प्रमाणीकरण प्रकार हो सकते हैं: उपयोगकर्ताओं, Google, Facebook, आदि के साथ आपका डीबी। जहां तक ​​मुझे याद है कि इसे साइन-इन पर जेनरेट की गई कुकी के दावे के रूप में जोड़ा गया है।

जब आप उपयोगकर्ता को साइन आउट करते हैं तो आपको प्रमाणीकरण प्रदाता को जानने की आवश्यकता होती है। अपने प्रमाणीकरण मिडलवेयर इस तरह परिभाषित किया गया है:

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
     LoginPath = new PathString("/Login/"), 
     AuthenticationType = "My-Magical-Authentication", 
     // etc... 
     }, 
    }); 

तो उपयोगकर्ता साइन आउट करने के आप एक ही जादू स्ट्रिंग की जरूरत है: AuthenticationManager.SignOut("My-Magical-Authentication")

इसके अलावा इस स्ट्रिंग ClaimsIdentity में पारित हो जाता है जब प्रमुख बनाया जाता है।और AuthenticationType प्रिंसिपल बिना because प्रमाणित नहीं किया जा सकता है:

/// <summary> 
/// Gets a value that indicates whether the identity has been authenticated. 
/// </summary> 
/// 
/// <returns> 
/// true if the identity has been authenticated; otherwise, false. 
/// </returns> 
public virtual bool IsAuthenticated 
{ 
    get 
    { 
    return !string.IsNullOrEmpty(this.m_authenticationType); 
    } 
} 

इस विधि IsAuthenticated सब प्रमाणीकरण तंत्र इस पर निर्भर के साथ, पूरी MVC कोड आधार के माध्यम से किया जाता है।

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

एक अन्य प्रयोग मैं सिर्फ पाया - अगर आप अपने मिडलवेयर विन्यास में CookieName प्रदान नहीं करते हैं, तो Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; (see second if statement in constructor)।

मुझे यकीन है कि वहां और अधिक जगहें हैं जहां इसका उपयोग किया जाता है। लेकिन सबसे महत्वपूर्ण यह है कि इसे प्रदान करना और नाम के साथ संगत होना या आपको प्रमाणीकरण प्रणाली में सूक्ष्म बग मिलेंगे।

Answer 2

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

मेरे पास एक बहु-किरायेदार वेबसाइट है: वेबसाइट एक ही उदाहरण के रूप में चलती है एकाधिक डोमेन उससे जुड़े होते हैं। प्रत्येक डोमेन एक अलग किरायेदार (उपयोगकर्ताओं के एक अलग सेट के साथ) है। प्रति किरायेदार एक फेसबुक लॉगिन को लागू करने के लिए, मुझे प्रति किरायेदार एक फेसबुक ऐप की आवश्यकता थी। इस कॉन्फ़िगर करने के लिए, मैं एक अद्वितीय CallbackPath और किरायेदार प्रति एक अनूठा AuthenticationType स्थापित करने के लिए किया था:

var facebookOptions = new FacebookAuthenticationOptions 
{ 
    AuthenticationType = "Facebook-{tenantID}", 
    CallbackPath = new PathString($"/signin-facebook-{tenantID}") 
} 

मैंने सोचा कि यह भी एक कुकी नाम के रूप में इस्तेमाल किया गया था, लेकिन उस FacebookAuthentication की तरह एक बाहरी प्रवेश के लिए ऐसा नहीं है।

1. authenticationManager.GetExternalLoginInfoAsync() के माध्यम से IdentityUserLogin.LoginProvider
2. authenticationManager.GetExternalAuthenticationTypes() (के माध्यम से AuthenticationDescription.AuthenticationType तार्किक ;-) लगता है: क्या मैं नोटिस किया था कि AuthenticationType की इस मान को ऊपर पॉप जब अनुरोध कर रहा है) प्रत्येक user.Logins (1 के समान)

और अंत में कम से कम के लिए

IdentityUserLogin.LoginProvider: AuthenticationType का मूल्य डेटाबेस स्तंभ AspNetU में संग्रहित है serLogins.LoginProvider।

Answer 3

Startup.Auth में (के रूप में कोड यदि आप किसी अन्य अनुप्रयोग से नकल के खिलाफ) आप एक ताजा asp.net समाधान, मानक सेट अप कोड सेट अप लाइन AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

शामिल है, तो यह बनाता है एक कुकी (.spnet.AplicationCookie के डिफ़ॉल्ट नाम के साथ), जो आप देख सकते हैं कि क्या आप अपने ब्राउज़र की सक्रिय कुकी सूची में देखते हैं, जिसका उपयोग यह जांचने के लिए किया जाता है कि उपयोगकर्ता प्रत्येक अनुरोध के लिए प्रमाणीकृत है या नहीं। कुकी वहाँ नहीं है (या उपयोगकर्ता किसी तरह प्रमाणीकृत नहीं में है), तो मिडलवेयर मार्ग अपनी लाइन LoginPath = new PathString("/Login/"),

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

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

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