IIS 7.5: Windows प्रमाणीकरण के साथ कस्टम प्रमाणीकरण त्रुटि पृष्ठ को कॉन्फ़िगर कैसे करें। 401 हेडर समस्याएं


14

मेरे पास IIS 7.5 के तहत एक php वेबसाइट है। साइट Windows प्रमाणीकरण द्वारा सुरक्षित है और यह ठीक काम करती है:

विंडोज ऑथेंटिकेशन चालू है

जब उपयोगकर्ता साइट पर जाते हैं, तो उन्हें उपयोगकर्ता नाम / पासवर्ड के लिए कहा जाता है और यदि प्रमाणित किया जाता है तो उसके माध्यम से प्राप्त किया जाता है। यदि उपयोगकर्ता 3 बार रद्द या गलत पासवर्ड पर क्लिक करते हैं, तो उन्हें 401 त्रुटि पृष्ठ दिखाया गया है:

बदसूरत 401 पृष्ठ

अब मैं कस्टम पेज दिखाना चाहूंगा कि लॉग-इन कैसे करें। इसलिए मैं त्रुटि पृष्ठों पर जाता हूं, स्थिति कोड 401.2 का चयन करता हूं और उस पृष्ठ पर इंगित करता हूं जिसे मैं प्रदर्शित करना चाहता हूं:

त्रुटि पृष्ठ सेटिंग्स

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

यहां क्या होता है: पृष्ठ के लिए पहले अनुरोध पर IIS 401-हेडर भेजने की कोशिश करता है, लेकिन यह नोटिस करता है कि web.config "इस पृष्ठ पर 401 रीडायरेक्ट पर" कहता है। और प्रमाणीकरण के बजाय, यह सिर्फ पुनर्निर्देशित पृष्ठ देता है।

मैंने 401, 401.1, 401.2 की जगह लेने की कोशिश की है - कोई फर्क नहीं पड़ा।

मैं क्या गलत कर रहा हूं और उपयोगकर्ता प्रमाणीकरण त्रुटि पर कस्टम पृष्ठ कैसे दे सकता हूं?

ps यहाँ web.config है:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Custom">
            <remove statusCode="500" subStatusCode="-1" />
            <remove statusCode="404" subStatusCode="-1" />
            <remove statusCode="401" subStatusCode="-1" />
            <error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />
            <error statusCode="404" prefixLanguageFilePath="" path="/not_restricted/404.htm" responseMode="ExecuteURL" />
        </httpErrors>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
    <system.web>
        <identity impersonate="false" />
        <customErrors defaultRedirect="http://www.myserver.com/not_restricted/500.htm" mode="Off">
        </customErrors>
    </system.web>
</configuration>

जवाबों:


15

इसे इस्तेमाल करे:

परिवर्तन:

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />

सेवा

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />

प्रतिक्रिया मोड 'फ़ाइल' के साथ IIS सिर्फ उस फ़ाइल की सामग्री को लोड करता है और इसे प्रदर्शित करता है, यह अभी भी क्लाइंट को 401 स्थिति भेजता है।

मैं 'ExecuteURL' का उपयोग करता था लेकिन मैंने सीखा है कि फ़ाइल मोड बहुत बेहतर काम करता है। आपको बस यह सुनिश्चित करना है कि आपके त्रुटि पृष्ठों में कोई भी लिंक किए गए संसाधन अभी भी काम करते हैं।


1
सर, आप एक स्टार हैं! कि पहले प्रयास से समस्या तय हो गई!
ट्रेलमैक्स

2

मैं कस्टम कैंपरों को जोड़ने के बाद क्रेडेंशियल्स के साथ प्रेरित नहीं होने के उपयोगकर्ताओं के इसी मुद्दे में भाग गया और इसे 0. के एक सबस्टैटसकोड के साथ ठीक करने में सक्षम था। आशा है कि यह किसी को मदद करता है।

<error statusCode="401" subStatusCode="0" path="..." responseMode="ExecuteURL">

1

इसलिए मुझे बेसिक ऑथ की ठीक उसी समस्या के साथ एक कठिन समय हो रहा था जो ब्राउज़र को संकेत नहीं दे रहा था। न तो 401.0 की कस्टम त्रुटि को मजबूर करने (यानी स्पष्ट रूप से सबकोड को 0 पर सेट करना) या रजिस्ट्री कुंजी निर्माण की स्थापना ने इसे मेरे लिए हल कर दिया।

यह शुरू करने के लिए कस्टम त्रुटि पृष्ठों का हमारा उपयोग था। उन्हें बंद कर दिया, सब कुछ ठीक काम किया, पर वापस ... विशेष रूप से 401 (0) और 401.2 त्रुटियों को शीघ्र रोका।

कस्टम त्रुटि प्रकार को 'ExecuteURL' से 'फ़ाइल' में सेट करना इसे हल करता है, लेकिन यदि उपयोगकर्ता ने संकेत को रद्द कर दिया या एक खराब पासवर्ड दर्ज किया, तो उन्हें एक जेनेरिक मिला "आपको इस निर्देशिका या पृष्ठ को देखने की अनुमति नहीं है"।

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

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

वैसे भी, उम्मीद है कि यह किसी की मदद करता है।


0

मेरे मामले में कुछ अजीब कारण के लिए 2 समाधानों के संयोजन ने मेरे लिए asp.net MVC 5 के लिए काम किया।

  <error statusCode="401" subStatusCode="0" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />

यह स्वीकृत उत्तर के रूप में सटीक उत्तर है।
चमकदार

स्थिति कोड अलग है।
तेमन शिपाही
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.