Используя Windows 2008r2, IIS 7.5, у меня есть приложение, использующее встроенную проверку подлинности Windows (WWW-Authenticate: NTLM, Negotiate).
В моем коде ASP.NET MVC я перезаписываю вывод страницы ошибок IIS ...
protected void Application_EndRequest(Object sender, EventArgs e)
{
HttpContext context = ((HttpApplication)sender).Context;
if (context.Response.Status.Substring(0, 3).Equals("401"))
{
HttpApplication app = (HttpApplication)sender;
string returnUrl = Response.ApplyAppPathModifier("~/OpenId/AskUser").ToString();
string url = new Uri(this.Request.Url, Response.ApplyAppPathModifier("~/Account/Login?returnUrl=" + returnUrl)).ToString();
app.Response.ClearContent();
app.Response.Write(string.Format("<!DOCTYPE html><html lang=\"en\"><head><meta charset=\"utf-8\"><meta http-equiv=\"refresh\" content=\"0;URL='{0}'\"><title>Error Authenticating</title><script language=\"javascript\">self.location='{0}';</script></head><body>Error Authenticating</body></html>", url));
}
}
Цель состоит в том, чтобы перенаправить пользователя, если он работает на компьютере или мобильном устройстве, отличном от Windows (или использует Firefox на ПК с Windows), к логину на основе форм, который они могут использовать вместо ожидания своих учетных данных Windows через встроенную аутентификацию Windows.
Проблема, с которой я сталкиваюсь с IIS 7.5 на сервере, заключается в том, что даже если это событие EndRequest запускается (я могу сказать по заголовку X-DEBUG, который я вставил в код и наблюдая за скрипачом), вывод HTML, отправленный обратно клиенту, является Страница ошибки IIS 7.5 по умолчанию для кода состояния http 401, а не выводимая мной HTML-страница. При первой отправке запроса (первый запрос с ответом 401) он работает нормально, но если пользователь нажимает OK с пустой или неправильной комбинацией имени пользователя и пароля, последующие ответы 401 не включают правильный вывод в теле ответ (либо страница ответа IIS 7.5 401 по умолчанию, либо простое предложение текста без HTML).
Обратите внимание, что этого не происходит в IIS 7.5 Express в моем окне разработчика - он правильно выводит HTML-страницу из сегмента кода выше. Это происходит только тогда, когда я развертываю проект на веб-сервере IIS 7.5.
Я также попытался создать настраиваемую страницу ошибок ... в моем web.config я добавил следующее в system.webServer ...
<httpErrors>
<remove statusCode="401"/>
<error statusCode="401" prefixLanguageFilePath="" path="ErrorPages/401.html" responseMode="File" />
</httpErrors>
И создал и развернул соответствующий HTML-файл. Как только я это сделал, я больше не получил страницу ошибок IIS 7.5 по умолчанию, но теперь получаю только следующий краткий текстовый (не HTML) ответ: «У вас нет разрешения на просмотр этого каталога или страницы».
Я не понимаю, почему IIS Express все выводит правильно, а IIS 7.5 - нет. Даже когда я говорю IIS 7.5 вывести другую страницу для этого типа ошибки, он все равно этого не сделает.
Это похоже на дубликат https://stackoverflow.com/questions/434272/iis7-overrides-customerrors-when-setting-response-statuscode , но я слишком новичок в Server Fault, чтобы отмечать это.
Мое мнение: у меня была аналогичная проблема при использовании Mediawiki на сервере IIS.
Когда вы переходите на несуществующую страницу в Mediawiki. Он отправляет обратно специальную вики-страницу, в которой говорится, что страница не существует, и позволяет вам ее создать. Однако эта страница отправляется со статусом 404.
На стандартном сервере IIS IIS автоматически перезапишет его пользовательской страницей ошибок для пользователей, НЕ находящихся на локальном хосте, но отправит подробные сообщения об ошибках тем, кто находится. На практике «подробные сообщения об ошибках» означают пропуск исходной страницы с ошибкой, независимо от того, настроена ли она в вашем приложении или сгенерирована ASP.NET из-за ошибки кодирования.
Мой метод заключался в том, чтобы включить подробные сообщения об ошибках как для локальных, так и для удаленных пользователей в Страницах ошибок> Параметры функции. Однако это также позволит удаленным пользователям видеть подробные сообщения об ошибках ASP в случае их возникновения, что может помочь злоумышленнику поставить под угрозу вашу безопасность.
Другие варианты даны как ответы на связанный вопрос, в том числе лучшие, которые могут не иметь последствий для безопасности. Другой вариант в этом случае - не возвращать код состояния 401, а просто обычный код 200 с вашей настраиваемой страницей. Это приносит в жертву принципам REST ради простоты разработки.
Обратите внимание, что тот факт, что подробные сообщения об ошибках отображаются для локального пользователя, но не для удаленных, может объяснить, почему ваши решения работают во время локального тестирования, но не при развертывании.