IIS 7.5: Як налаштувати користувальницьку сторінку помилок аутентифікації за допомогою автентифікації Windows. Проблеми із заголовком 401

У мене веб-сайт, що працює під IIS 7.5. Сайт захищено автентифікацією Windows, і це прекрасно працює:

Коли користувачі переходять на сайт, їх запитують ім'ям користувача / паролем і отримують доступ, якщо вони підтверджені автентифікацією. Якщо користувачі натискають Скасувати або вводити пароль 3 рази, їм відображається сторінка 401 помилок:

Тепер я хотів би показати власну сторінку, що пояснює, як увійти. Тому я переходжу на сторінки помилок, вибираю код статусу 401.2 і вказую його на сторінку, яку я хотів би показати:

Потім переконайтеся, що спеціальні помилки включені для всіх. І каа-бум! Автентифікація більше не працює, користувачам не надається запит на введення пароля. Як зазначається в документації, автентифікація Windows працює, спочатку надсилаючи відповідь 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>

Спробуйте це:

зміни:

<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", але дізнався, що режим файлів працює набагато краще. Вам просто потрібно переконатися, що будь-які пов’язані ресурси на сторінках помилок все ще працюють.

Я зіткнувся з цим самим випуском користувачів, коли не додавали облікові дані після додавання користувальницьких https, і змогли виправити це за допомогою subStatusCode 0. Сподіваюся, це комусь допоможе.

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

Тож мені було важко з тією самою проблемою, як Basic Auth не підказувати браузер. Ані примушування до користувацької помилки 401.0 (тобто явного встановлення підкоду до 0), ні встановлення ключа реєстру не вирішило мене.

Виявилося, це було для початку використання користувацьких сторінок помилок. Відключивши їх, все спрацювало нормально, і знову ... зокрема, помилки 401 (0) та 401.2 запобігли запиту.

Встановлення користувальницького типу помилки на "Файл" з "ExecuteURL" вирішило його, але якщо користувач скасував підказку або ввів неправильний пароль, він отримав загальне "Ви не маєте дозволу на перегляд цього каталогу чи сторінки".

Після багатьох отриманих підказок з різних публікацій, але ніколи не було точного "як" чи "чому" ... Я використовував відносний шлях для файлу користувацьких помилок, який знаходився у підкаталозі сайту. Зміна шляху до абсолютного призвела до того, що вищезазначена загальна помилка була замінена на "Не можу відобразити цю сторінку", якщо її скасували або неправильний пароль. Ще трохи копав, і я знайшов постговорити про атрибут config "enableAbsolutePathsWhenDelegated", який за замовчуванням встановлено на false. Він також зазначає, що якщо ви просто помістите файл помилки клієнта в корінь свого сайту, а потім у користувацькому місці помилки лише ім'я файлу (тобто відносний шлях до кореня сайту), він буде працювати ... досить впевнено, що це робить, проте , Я не хотів вводити власні помилки в корінь свого сайту. Тому я використав ConfigurationEditor, щоб встановити вищезазначений атрибут true, встановив абсолютний шлях до спеціальних файлів помилок і все почало працювати нормально. Підказка залишилася, під час спрацьовування відображається користувацька помилка.

Мені б хотілося, щоб я міг використовувати атрибут File з вкладеним відносним шляхом, але поки що я не з'ясував, чому я не можу чи як це зробити. Інше питання, якщо я використовую абсолютний шлях, якщо я потенційно створюю отвір у захисті (тобто чому це буде відключено за замовчуванням?)

У будь-якому випадку, сподіваюся, що це комусь допоможе.

З якоїсь дивної причини у моєму випадку для asp.net MVC 5 працювали комбінації до 2 рішень.

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