IIS 7.5: Как настроить пользовательскую страницу ошибки аутентификации с помощью аутентификации Windows. 401 проблемы с заголовком

У меня есть сайт php, работающий под 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», но узнал, что режим «Файл» работает намного лучше. Вам просто нужно убедиться, что все связанные ресурсы на ваших страницах ошибок все еще работают.

Я столкнулся с той же проблемой, когда пользователи не получали учетные данные после добавления пользовательских httperrors и смогли исправить это с помощью subStatusCode, равного 0. Надеюсь, это кому-нибудь поможет.

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

Так что мне было трудно из-за той же самой проблемы, что Basic Auth не отображал браузер. Ни принудительная ошибка 401.0 (т. Е. Явное задание субкода равным 0), ни установка ключа реестра не решили ее для меня.

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

Если для пользовательского типа ошибки было указано «Файл» из «ExecuteURL», это помогло, но если пользователь отменил запрос или ввел неверный пароль, он получил общее «У вас нет разрешения на просмотр этого каталога или страницы».

Получив много подсказок из разных постов, но никогда не задавая точных «как» или «почему» ... я использовал относительный путь для файла пользовательских ошибок, который находился в подкаталоге сайта. Изменение пути на абсолютное привело к замене вышеуказанной общей ошибки на «невозможно отобразить эту страницу» в случае отмены или неверного пароля. Еще немного покопался и я нашел постречь идет о атрибуте конфигурации "allowAbsolutePathsWhenDelegated", который по умолчанию имеет значение false. В нем также говорится, что если вы просто поместите файл ошибок клиента в корень своего сайта, а затем в пользовательское место ошибки просто имя файла (то есть относительный путь к корню сайта), это будет работать ... конечно, это так, однако Я не хотел помещать пользовательские ошибки в корень моего сайта. Поэтому я использовал ConfigurationEditor, чтобы установить для вышеприведенного атрибута значение true, установить абсолютный путь к файлам пользовательских ошибок, и все стало работать нормально. Запрос остался, пользовательская ошибка отображается при срабатывании.

Я хотел бы иметь возможность использовать атрибут File с вложенным относительным путем, но до сих пор я не понял, почему я не могу или как это сделать. Другой вопрос, если с помощью абсолютного пути я потенциально создаю дыру в безопасности (то есть, почему это было бы отключено по умолчанию?)

В любом случае, надеюсь, это кому-нибудь поможет.

По какой-то странной причине в моем случае комбинация до 2-х решений сработала для asp.net MVC 5.

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