IIS 7.5: Jak skonfigurować niestandardową stronę błędu uwierzytelnienia przy użyciu uwierzytelniania systemu Windows. 401 problemów z nagłówkiem

Mam witrynę php działającą pod IIS 7.5. Witryna jest zabezpieczona przez uwierzytelnianie systemu Windows i działa dobrze:

Gdy użytkownicy przechodzą do witryny, są proszeni o podanie nazwy użytkownika / hasła i przejście, jeśli są uwierzytelnione. Jeśli użytkownicy klikną Anuluj lub trzykrotnie wprowadzą hasło, wyświetli się strona błędu 401:

Teraz chciałbym wyświetlić niestandardową stronę wyjaśniającą sposób logowania. Więc przechodzę do stron błędów, wybieram kod stanu 401.2 i wskazuję stronę, którą chciałbym wyświetlić:

Następnie upewnij się, że niestandardowe błędy są włączone dla wszystkich. I kaa-boom! Uwierzytelnianie nie działa, użytkownicy nie są proszeni o podanie hasła. Jak wynika z dokumentacji, uwierzytelnianie systemu Windows polega na tym, że najpierw wysyła odpowiedź 401, a następnie przeglądarka pyta użytkownika o poświadczenia dostawcy, a następnie zastanawia się, co dalej.

Co się dzieje tutaj: na pierwsze żądanie strony IIS próbuje wysłać nagłówek 401, ale zauważa, że ​​web.config mówi „na przekierowaniu 401 na tę stronę”. I zamiast uwierzytelniania, po prostu daje stronę przekierowania.

Próbowałem wymienić 401, 401.1, 401.2 - nie zrobiłem żadnej różnicy.

Co robię źle i jak podać niestandardową stronę dotyczącą błędu uwierzytelnienia użytkownika?

ps Oto 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>

Spróbuj tego:

zmiana:

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

do

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

W trybie odpowiedzi „Plik” IIS po prostu ładuje zawartość tego pliku i wyświetla go, nadal wysyła status 401 z powrotem do klienta.

Kiedyś używałem „ExecuteURL”, ale dowiedziałem się, że tryb pliku działa znacznie lepiej. Musisz tylko upewnić się, że wszelkie połączone zasoby na stronach błędów nadal działają.

Natknąłem się na ten sam problem polegający na tym, że użytkownicy nie otrzymali monitu o podanie poświadczeń po dodaniu niestandardowych haseł https i mogłem to naprawić za pomocą kodu subStatusCode równego 0. Mam nadzieję, że to komuś pomoże.

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

Miałem więc trudności z dokładnie tym samym problemem, co w przypadku uwierzytelniania podstawowego, który nie wyświetlał monitu w przeglądarce. Ani wymuszenie niestandardowego błędu 401,0 (tj. Jawne ustawienie subkodu na 0), ani ustawienie tworzenia klucza rejestru nie rozwiązało go.

Okazało się, że na początek wykorzystaliśmy niestandardowe strony błędów. Po ich wyłączeniu wszystko działało poprawnie, włączyło się ponownie ... konkretnie błędy 401 (0) i 401,2 uniemożliwiły wyświetlenie monitu.

Ustawienie niestandardowego typu błędu na „Plik” z „ExecuteURL” rozwiązało go, ale jeśli użytkownik anuluje monit lub wprowadzi złe hasło, otrzyma ogólny komunikat „Nie masz uprawnień do przeglądania tego katalogu lub strony”.

Po wielu wskazówkach z różnych postów, ale nigdy nie było to dokładne „jak to zrobić” ani „dlaczego” ... użyłem ścieżki względnej dla niestandardowego pliku błędu, który znajdował się w podkatalogu witryny. Zmiana ścieżki na bezwzględną spowodowała, że ​​powyższy błąd ogólny został zastąpiony przez „nie można wyświetlić tej strony” w przypadku anulowania lub złego hasła. Trochę więcej kopania i znalazłem postmówiąc o atrybucie config „allowAbsolutePathsWhenDelegated”, który jest domyślnie ustawiony na false. Stwierdza również, że jeśli po prostu umieścisz plik błędu klienta w katalogu głównym witryny, a następnie w niestandardowej lokalizacji błędu tylko nazwa pliku (tj. Ścieżka względna do katalogu głównego witryny), to zadziała ... na pewno jednak tak się stanie , Nie chciałem umieszczać niestandardowych błędów w katalogu głównym mojej witryny. Użyłem więc ConfigurationEditora, aby ustawić powyższy atrybut na true, ustawić bezwzględną ścieżkę do niestandardowych plików błędów i wszystko zaczęło działać dobrze. Monit pozostał, błąd niestandardowy wyświetla się po uruchomieniu.

Chciałbym móc użyć atrybutu Plik z zagnieżdżoną ścieżką względną, ale jak dotąd nie dowiedziałem się, dlaczego nie mogę i jak to zrobić. Drugim pytaniem jest, jeśli używając ścieżki bezwzględnej, czy potencjalnie tworzę lukę bezpieczeństwa (tj. Dlaczego miałoby to być domyślnie wyłączone)?

W każdym razie mam nadzieję, że to komuś pomoże.

Z jakiegoś dziwnego powodu w moim przypadku kombinacja maksymalnie 2 rozwiązań działała dla mnie dla asp.net MVC 5.

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