JQuery के उपयोग से ब्राउज़र को बुनियादी कोर पॉपअप को कैसे रोका जाए और 401 त्रुटि को हैंडल किया जाए?

Question

मुझे मूल अधिकार का उपयोग करके प्राधिकरण अनुरोध भेजने की आवश्यकता है। मैंने सफलतापूर्वक jquery का उपयोग करके इसे लागू किया है। हालाँकि जब मुझे 401 एरर मिलता है तो बेसिक ऑर्ट ब्राउज़र ब्राउज़र पॉपअप खुल जाता है और jquery ajax एरर कॉलबैक नहीं कहा जाता है।

Comments

के संभावित डुप्लिकेट मैं ब्राउज़र के प्रमाणीकरण संवाद कैसे दबाने सकते?

— कोरायेम

Answer 1

मैं हाल ही में इस मुद्दे का सामना कर रहा था। चूँकि आप पॉपअप 401( बेसिक या डाइजेस्ट ऑथेंटिकेशन) के मामले में पॉपअप दिखाने के ब्राउज़र के डिफ़ॉल्ट व्यवहार को नहीं बदल सकते हैं, इसे ठीक करने के दो तरीके हैं:

• वापसी नहीं करने के लिए सर्वर प्रतिक्रिया बदलें 401। 200इसके बजाय एक कोड लौटाएं और अपने jQuery क्लाइंट में इसे संभालें।

• उस विधि को बदलें जो आप अपने हेडर में कस्टम मूल्य के लिए प्राधिकरण के लिए उपयोग कर रहे हैं। ब्राउजर बेसिक और डाइजेस्ट के लिए पॉपअप प्रदर्शित करेगा । आपको इसे क्लाइंट और सर्वर दोनों पर बदलना होगा।

  headers : {
    "Authorization" : "BasicCustom"
  }
  

बेसिक ऑथ के साथ jQuery का उपयोग करने के उदाहरण के लिए कृपया इस पर एक नज़र डालें ।

Comments

WWW-Authenticate: xBasic realm = com.example, इसे क्लासिक 401 स्थिति कोड के साथ कर सकते हैं। इस ब्लॉग पोस्ट ने मुझे संकेत दिया (मैं ब्लॉग का स्वामी नहीं हूं) लाउडवंचर .blogspot.ca

— PM

@PM, ब्लॉग का जवाब एक सही समाधान है। ध्यान दें कि यदि <security:http-basic/>आप का उपयोग करने के लिए परिभाषित करने की आवश्यकता नहीं है, basicAuthenticationFilterलेकिन इसे परिभाषित करना चाहिए <security:http-basic entry-point-ref="myBasicAuthenticationEntryPoint"/>।

— ब्रेट रायन

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

— मोहम्मद उसी

किसी कारण से जब मैं लौट रहा हूँ तो मुझे पॉपअप मिल रहा है 401और WWW-Authenticate:Bearer WWW-Authenticate:NTLM WWW-Authenticate:Negotiateक्या आप जानते हैं कि ऐसा क्यों होगा

— DevEng

Answer 2

एक सामान्य 400 स्थिति कोड लौटाएँ, और फिर उस क्लाइंट-साइड पर प्रक्रिया करें।

या आप 401 को रख सकते हैं, और डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर को वापस नहीं कर सकते हैं, जो वास्तव में वह है जो ब्राउज़र प्रमाणीकरण के साथ प्रतिक्रिया दे रहा है। यदि WWW-Authenticate हेडर गायब है, तो ब्राउज़र क्रेडेंशियल के लिए संकेत नहीं देगा।

Comments

@MortenHaraldsen खैर 401 प्रतिक्रिया इस अवसर में देने के लिए उचित प्रतिक्रिया है, समस्या यह है कि ब्राउज़र स्वचालित रूप से इस देशी को संभाल रहा है, बजाय जावास्क्रिप्ट एप्लिकेशन को इसे संभालने की अनुमति देता है। मानक की सिफारिश की गई प्रतिक्रिया कोड को वापस करके, आप मानक से चिपके रह सकते हैं, जो मानक की सिफारिश करता है, या आप मानक से चिपके नहीं रहना चुन सकते हैं। अपनी पिक लें :)

— इब्राहिम

अपने एक्सप्रेस ऐप में, मैंने इसे एक लाइन के साथ तय किया: res.removeHeader('www-authenticate'); // prevents browser from popping up a basic auth window.

— gstroup

@ इब्राहीम, इसे खुद बेहतर नहीं कह सकते थे। मानक उन लोगों द्वारा बनाए जाते हैं जो बैठते हैं और बात करते हैं, जरूरी नहीं कि जो लोग बैठते हैं और कोड करते हैं।

— user2867288

Answer 3

आप मूल url को इस तरह से देख रहे अनुरोध url को दबा सकते हैं:

https://username:[e-mail]/admin/...

यदि आपको 401 त्रुटि (गलत उपयोगकर्ता नाम या पासवर्ड) मिलती है, तो इसे सही ढंग से jquery त्रुटि कॉलबैक से नियंत्रित किया जाएगा। यह कुछ सुरक्षा समस्याओं (https के बजाय http प्रोटोकॉल के मामले में) का कारण बन सकता है, लेकिन यह काम करता है।

UPD: क्रोम 59 में इस समाधान समर्थन को हटा दिया जाएगा

Comments

गजब का!!!! मेरी समस्या का हल 192.168.1.1 को हो रहा था और राउटर ने ऑथेन्टिकेशन के लिए कहा।

— नादव लेबोविच 10

यदि आप किसी भी ब्राउज़र में डेवलपर टूल के तहत "नेटवर्क" टैब पर जाते हैं, तो आप सादे पाठ में उपयोगकर्ता नाम और पासवर्ड पढ़ने में सक्षम हैं। यह काम करता है, यद्यपि।

— ब्रूनो फिंगर

कृपया ऐसा कभी न करें, आपके वेबसर्वर पर लॉग लॉग अब मेरे लिए बहुत अधिक मूल्यवान हैं .. नि: शुल्क उपयोगकर्ता नाम और पासवर्ड कॉम्बो के प्लस प्रतिक्रिया कोड! धन्यवाद

— Remco

लेकिन कोई उपयोगकर्ता नाम और पासवर्ड को देखने से कैसे रोक सकता है

— sdx11

इस प्रमाणीकरण विधि का मूल्य ह्रास हो रहा है और क्रोम एम्बेडेड क्रेडेंशियल्स यानी https://user:pass@host/M59 के लिए जून 2017 के आसपास समर्थन छोड़ देगा । अधिक जानकारी के लिए यह क्रोमेस्टैटस ब्लॉग पोस्ट देखें ।

— गैरिएवो

Answer 4

जैसा कि अन्य ने बताया है, ब्राउज़र के व्यवहार को बदलने का एकमात्र तरीका यह सुनिश्चित करना है कि प्रतिक्रिया में या तो 401 स्थिति कोड नहीं है या यदि यह है, तो WWW-Authenticate: Basicहेडर शामिल नहीं है । चूंकि स्टेटस कोड बदलना बहुत अर्थपूर्ण और अवांछनीय नहीं है, WWW-Authenticateहेडर को निकालने के लिए एक अच्छा तरीका है । यदि आप अपने वेब सर्वर एप्लिकेशन को संशोधित नहीं कर सकते हैं या नहीं करना चाहते हैं, तो आप इसे हमेशा अपाचे के माध्यम से सेवा या प्रॉक्सी कर सकते हैं (यदि आप अपाचे का उपयोग नहीं कर रहे हैं)।

डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर को हटाने के लिए प्रतिक्रिया को फिर से लिखने के लिए अपाचे के लिए एक कॉन्फ़िगरेशन है IFF अनुरोध में हेडर शामिल है X-Requested-With: XMLHttpRequest(जो डिफ़ॉल्ट रूप से JQuery / AngularJS जैसे प्रमुख जावास्क्रिप्ट फ्रेमवर्क द्वारा सेट किया गया है, आदि ... और प्रतिक्रिया में शामिल है) हेडर WWW-Authenticate: Basic।

Apache 2.4 पर परीक्षण किया गया (सुनिश्चित नहीं है कि यह 2.2 के साथ काम करता है)। यह mod_headersस्थापित किए जा रहे मॉड्यूल पर निर्भर करता है। (डेबियन / उबंटू पर, sudo a2enmod headersऔर अपाचे को पुनरारंभ करें)

    <Location />
            # Make sure that if it is an XHR request,
            # we don't send back basic authentication header.
            # This is to prevent the browser from displaying a basic auth login dialog.
            Header unset WWW-Authenticate "expr=req('X-Requested-With') == 'XMLHttpRequest' && resp('WWW-Authenticate') =~ /^Basic/"
    </Location>   

Comments

Nginx के साथ भी ऐसा करने के लिए, सेट करेंproxy_hide_header WWW-Authenticate;

— Cuga

Answer 5

X-Requested-With: XMLHttpRequest का उपयोग अपने अनुरोध हैडर के साथ करें। तो प्रतिक्रिया शीर्षलेख में WWW-Authenticate: Basic नहीं होगा।

beforeSend: function (xhr) {
                    xhr.setRequestHeader('Authorization', ("Basic "
                        .concat(btoa(key))));
                    xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
                },

Comments

मेरे लिए इसका कोई प्रभाव नहीं था। जब आप XMLHttpRequest सेट करते हैं तो WWW-Authenticate को किस प्रकार के सर्वर का उपयोग नहीं किया जाता है?

— रॉबर्ट एंटोउकी

@ रोबर्टनटनुची यह अपाचे

— टोमैट है

Answer 6

यदि आप IIS सर्वर का उपयोग कर रहे हैं, तो आप अनुरोधित URL पर WWW-Authenticationहेडर को फिर से लिखने के लिए IIS URL रिवाइटरिंग (v2) सेटअप कर सकते हैं None।

यहां मार्गदर्शन करें ।

जिस मान को आप बदलना चाहते हैं, वह है response_www_authenticate।

यदि आपको अधिक जानकारी की आवश्यकता है, तो एक टिप्पणी जोड़ें और मैं web.config फ़ाइल पोस्ट करूँगा।

Comments

इसने बहुत अच्छा काम किया। मैं यह नोट करना चाहूंगा कि IIS 7.5 पर URL रिवाइ्रट v2 में "प्रतिक्रिया" भाग को "RESPONSE_www_authenticate" लिखा जाना चाहिए।

— माइकल फ्रीमैन

Answer 7

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

Comments

यह बहुत महत्वपूर्ण है, बिल्कुल हाजिर है।

— तेज विंगफील्ड

Answer 8

वैकल्पिक रूप से, यदि आप अपने सर्वर की प्रतिक्रिया को अनुकूलित कर सकते हैं, तो आप 403 निषिद्ध वापस कर सकते हैं।

ब्राउज़र प्रमाणीकरण पॉपअप नहीं खोलेगा और jquery कॉलबैक कहा जाएगा।

Comments

यह HTTP 1.1 विनिर्देश के खिलाफ जाता है, जहां यह कहा गया है कि "... प्राधिकरण मदद नहीं करेगा और अनुरोध नहीं किया जाएगा" दोहराया नहीं जाना चाहिए।

— जुका डाहलबॉम

यह 403 प्राप्त करने के लिए वैध है, जबकि संसाधनों के लिए आपको अनुमति नहीं दी जाती है, 401 को भेजा जाना चाहिए, जहां आपको अभी तक प्रमाणित नहीं किया गया है।

— ब्रेट रायन

Answer 9

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

    var xmlhttp=new XMLHttpRequest;
    xmlhttp.withCredentials=true;
    xmlhttp.open("POST",<YOUR UR>,false,username,password);
    xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
    xmlhttp.setRequestHeader('X-Requested-With', 'XMLHttpRequest');

Comments

अन्य संदर्भों में, "POST" के बजाय "विकल्प" का उपयोग करने से भी मदद मिल सकती है।

— इमैनुएल सेल्फीयर

Answer 10

GET के माध्यम से "उपयोगकर्ता" और "पासवर्ड" मापदंडों को स्वीकार करने के बजाय / लॉगिन url बनाएं, और बुनियादी स्थिति की आवश्यकता नहीं है। यहां, जो भी आपके पासवार्ड फाइल और पार्स फाइल करता है, उसके खिलाफ php, node, java का उपयोग करें और इसके खिलाफ पैरामीटर (उपयोगकर्ता / पास) का मिलान करें। यदि कोई मेल है तो http: // उपयोगकर्ता: [e-mail]/ (यह आपके ब्राउज़र पर क्रेडेंशियल सेट करेगा) को अनुप्रेषित करता है , यदि नहीं, तो 401 प्रतिक्रिया (WWW-Authenticate हेडर के बिना) भेजें।

Comments

बीच के हमलों में सादे-पाठ आदमी से उपयोगकर्ता नाम / पासवर्ड को सूँघने की कोशिश करने वालों के लिए यह बहुत अच्छा होगा!

— अजाक्स

Answer 11

स्प्रिंग बूट के साथ पीछे की ओर से मैंने कस्टम BasicAuthenticationEntryPoint का उपयोग किया है:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.cors().and().authorizeRequests()
            ...
            .antMatchers(PUBLIC_AUTH).permitAll()
            .and().httpBasic()
//    https://www.baeldung.com/spring-security-basic-authentication
            .authenticationEntryPoint(authBasicAuthenticationEntryPoint())
            ...

@Bean
public BasicAuthenticationEntryPoint authBasicAuthenticationEntryPoint() {
    return new BasicAuthenticationEntryPoint() {
        {
            setRealmName("pirsApp");
        }

        @Override
        public void commence
                (HttpServletRequest request, HttpServletResponse response, AuthenticationException authEx)
                throws IOException, ServletException {
            if (request.getRequestURI().equals(PUBLIC_AUTH)) {
                response.sendError(HttpStatus.PRECONDITION_FAILED.value(), "Wrong credentials");
            } else {
                super.commence(request, response, authEx);
            }
        }
    };
}