javascript मैं ब्राउज़र के प्रमाणीकरण संवाद को कैसे दबा सकता हूं?




ajax http-authentication (9)

मेरे वेब एप्लिकेशन में एक लॉगिन पृष्ठ है जो एक AJAX कॉल के माध्यम से प्रमाणीकरण प्रमाण-पत्र सबमिट करता है। यदि उपयोगकर्ता सही उपयोगकर्ता नाम और पासवर्ड में प्रवेश करता है, तो सब कुछ ठीक है, लेकिन यदि नहीं, तो निम्न होता है:

  1. वेब सर्वर निर्धारित करता है कि हालांकि अनुरोध में एक अच्छी तरह से गठित प्राधिकरण शीर्षलेख शामिल था, हेडर में प्रमाण-पत्र सफलतापूर्वक प्रमाणित नहीं होते हैं।
  2. वेब सर्वर एक 401 स्टेटस कोड देता है और समर्थित प्रमाणीकरण प्रकारों को सूचीबद्ध करने वाले एक या अधिक WWW- प्रमाणीकरण शीर्षलेख शामिल करता है।
  3. ब्राउजर का पता लगाता है कि XMLHttpRequest ऑब्जेक्ट पर मेरी कॉल का जवाब एक 401 है और प्रतिक्रिया में डब्ल्यूडब्ल्यूडब्लू-प्रमाणीकरण हेडर शामिल हैं। इसके बाद उपयोगकर्ता नाम और पासवर्ड के लिए फिर से एक प्रमाणीकरण संवाद पॉप अप करता है।

यह चरण 3 तक ठीक है। मैं नहीं चाहता कि संवाद पॉप अप हो, मैं अपने AJAX कॉलबैक फ़ंक्शन में 401 प्रतिक्रिया को संभालना चाहता हूं। (उदाहरण के लिए, लॉगिन पेज पर एक त्रुटि संदेश प्रदर्शित करके।) मैं चाहता हूं कि उपयोगकर्ता अपना उपयोगकर्ता नाम और पासवर्ड दोबारा दर्ज कर ले, लेकिन मैं चाहता हूं कि वे मेरे दोस्ताना, आश्वस्त लॉगिन फॉर्म को देखें, ब्राउज़र की बदसूरत, डिफ़ॉल्ट नहीं प्रमाणीकरण संवाद।

संयोग से, मेरे पास सर्वर पर कोई नियंत्रण नहीं है, इसलिए इसे एक कस्टम स्टेटस कोड (यानी, 401 के अलावा कुछ और) वापस करने का विकल्प नहीं है।

क्या कोई तरीका है कि मैं प्रमाणीकरण संवाद को दबा सकता हूं? विशेष रूप से, क्या मैं फ़ायरफ़ॉक्स 2 या बाद में प्रमाणीकरण आवश्यक संवाद को दबा सकता हूं? IE 6 और बाद में कनेक्ट को [होस्ट] संवाद को दबाने का कोई तरीका है?

संपादित करें
लेखक से अतिरिक्त जानकारी (सितंबर 18):
मुझे यह जोड़ना चाहिए कि ब्राउजर के प्रमाणीकरण संवाद के साथ वास्तविक समस्या यह है कि यह उपयोगकर्ता को अपर्याप्त जानकारी देता है।

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

संवाद इस तथ्य की कोई स्वीकृति नहीं देता है कि उसने अभी उपयोगकर्ता नाम और पासवर्ड दर्ज किया है । यह स्पष्ट रूप से यह नहीं बताता कि एक समस्या थी और उसे फिर से प्रयास करना चाहिए। इसके बजाए, संवाद बॉक्स उपयोगकर्ता को गुप्त जानकारी के साथ प्रस्तुत करता है जैसे "साइट कहता है: ' [realm] '। जहां [दायरे] एक छोटा सा नाम है जहां केवल एक प्रोग्रामर प्यार कर सकता है।

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


जब आप XMLHttpRequest ऑब्जेक्ट बनाते हैं तो आप मोज़िला में निम्न स्क्रिप्ट के साथ इसे प्राप्त कर सकते हैं:

xmlHttp=new XMLHttpRequest();
xmlHttp.mozBackgroundRequest = true;
xmlHttp.open("GET",URL,true,USERNAME,PASSWORD);
xmlHttp.send(null);

दूसरी पंक्ति संवाद बॉक्स को रोकती है ....


मुझे यहां एक ही समस्या का सामना करना पड़ा, और मेरी कंपनी के बैकएंड इंजीनियर ने एक ऐसा व्यवहार लागू किया जिसे स्पष्ट रूप से एक अच्छा अभ्यास माना जाता है: जब एक यूआरएल को कॉल 401 देता है, तो क्लाइंट ने हेडर X-Requested-With: XMLHttpRequest , सर्वर इसकी प्रतिक्रिया में www-authenticate शीर्षलेख छोड़ देता है।

दुष्प्रभाव यह है कि डिफ़ॉल्ट प्रमाणीकरण पॉपअप प्रकट नहीं होता है।

सुनिश्चित करें कि आपके एपीआई कॉल में X-Requested-With header शीर्षक है XMLHttpRequest सेट है। यदि ऐसा है तो इस अच्छे अभ्यास के अनुसार सर्वर व्यवहार को बदलने के अलावा कुछ भी नहीं है ...


उन असंगत सी # यहां ActionAttribute जो 401 बजाय 400 लौटाता है, और मूल लेख संवाद 'निगलता है'।

public class NoBasicAuthDialogAuthorizeAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        base.HandleUnauthorizedRequest(filterContext);
        filterContext.Result = new HttpStatusCodeResult(400);
    }
}

निम्नलिखित की तरह उपयोग करें:

[NoBasicAuthDialogAuthorize(Roles = "A-Team")]
public ActionResult CarType()
{
 // your code goes here
}

उम्मीद है कि यह आपको कुछ समय बचाता है।


मोज़िला भूमि में, XMLHttpRequest ( docs ) के mozBackgroundRequest पैरामीटर को सही करने के लिए उन संवादों को दबा देता है और अनुरोधों को बस विफल करने का कारण बनता है। हालांकि, मुझे नहीं पता कि क्रॉस-ब्राउज़र समर्थन कितना अच्छा है (जिसमें उन असफल अनुरोधों पर त्रुटि जानकारी की गुणवत्ता ब्राउज़र में बहुत अच्छी है।)


मैं नोड, एक्सप्रेस और पासपोर्ट का उपयोग कर रहा हूं और एक ही मुद्दे से संघर्ष कर रहा था। मुझे स्पष्ट रूप से www-authenticate शीर्षलेख को खाली स्ट्रिंग पर सेट करके काम करने के लिए मिला। मेरे मामले में, ऐसा लगता है:

(err, req, res, next) => {
  if (err) {
    res._headers['www-authenticate'] = ''
    return res.json(err)
  }
}

मुझे उम्मीद है कि किसी की मदद करता है!


मुझे नहीं लगता कि यह संभव है - यदि आप ब्राउज़र के HTTP क्लाइंट कार्यान्वयन का उपयोग करते हैं, तो यह हमेशा उस संवाद को पॉप अप करेगा। दो हैक्स दिमाग में आते हैं:

  1. हो सकता है कि फ्लैश इसे अलग-अलग संभालें (मैंने अभी तक कोशिश नहीं की है), इसलिए फ्लैश मूवी होने से अनुरोध मदद कर सकता है।

  2. आप उस सेवा के लिए 'प्रॉक्सी' सेट अप कर सकते हैं जिसे आप अपने सर्वर पर एक्सेस कर रहे हैं, और इसे प्रमाणीकरण हेडर को थोड़ा सा संशोधित कर सकते हैं, ताकि ब्राउजर उन्हें पहचान न सके।


जब निम्न दोनों शर्तों को पूरा किया जाता है तो ब्राउजर एक लॉगिन प्रॉम्प्ट पॉप अप करता है:

  1. HTTP स्थिति 4xx है
  2. WWW-Authenticate हेडर प्रतिक्रिया में मौजूद है

यदि आप HTTP प्रतिक्रिया को नियंत्रित कर सकते हैं, तो आप प्रतिक्रिया से WWW-Authenticate शीर्षलेख को हटा सकते हैं, और ब्राउज़र लॉगिन संवाद पॉपअप नहीं करेगा।

यदि आप प्रतिक्रिया को नियंत्रित नहीं कर सकते हैं, तो आप प्रतिक्रिया से WWW-Authenticate शीर्षलेख को फ़िल्टर करने के लिए प्रॉक्सी सेट कर सकते हैं।

जहां तक ​​मुझे पता है (अगर मैं गलत हूं तो मुझे सही करने के लिए स्वतंत्र महसूस करें), ब्राउज़र को WWW-Authenticate शीर्षलेख प्राप्त करने के बाद लॉगिन प्रॉम्प्ट को रोकने का कोई तरीका नहीं है।


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

<customErrors defaultRedirect="~/Error"  >
  <error statusCode="401" redirect="~/Index"/>
</customErrors>

इस प्रकार यह काम किया है क्योंकि घर नियंत्रक के तहत सूचकांक कार्रवाई उपयोगकर्ता को मान्य करती है। इस क्रिया में दृश्य, यदि लॉगऑन असफल है, तो लॉगिन नियंत्रण है जिसका उपयोग मैं निर्देशिका सेवाओं में पारित एलडीएपी क्वेरी का उपयोग कर उपयोगकर्ता को लॉग इन करने के लिए करता हूं:

      DirectoryEntry entry = new DirectoryEntry("LDAP://OurDomain");
      DirectorySearcher Dsearch = new DirectorySearcher(entry);
      Dsearch.Filter = "(SAMAccountName=" + UserID + ")";
      Dsearch.PropertiesToLoad.Add("cn");

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


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







http-authentication