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 - без разницы.

Что я делаю не так и как выдать настраиваемую страницу при ошибке аутентификации пользователя?

p.s. Вот файл 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 с вложенным относительным путем, но пока я не выяснил, почему я не могу и как это сделать. Другой вопрос, если, используя абсолютный путь, я потенциально создаю дыру в безопасности (т.е. почему это должно быть отключено по умолчанию?)

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

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

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