Запретить FormsAuthenticationModule для перехвата ответов ASP.NET Web API
В ASP.NET модуль FormsAuthenticationModule перехватывает любой HTTP 401 и возвращает перенаправление HTTP 302 на страницу входа. Это боль для AJAX, поскольку вы запрашиваете json и получаете страницу входа в html, но код состояния - HTTP 200.
Каков способ избежать этого перехвата в веб-API ASP.NET?
В ASP.NET MVC4 очень легко предотвратить этот перехват, явно констатируя соединение:
public class MyMvcAuthFilter:AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAjaxRequest() && !filterContext.IsChildAction)
{
filterContext.Result = new HttpStatusCodeResult(401);
filterContext.HttpContext.Response.StatusCode = 401;
filterContext.HttpContext.Response.SuppressContent = true;
filterContext.HttpContext.Response.End();
}
else
base.HandleUnauthorizedRequest(filterContext);
}
}
Но в ASP.NET Web API я не могу закончить соединение явно, поэтому даже когда я использую этот код, FormsAuthenticationModule перехватывает ответ и отправляет перенаправление на страницу входа в систему:
public class MyWebApiAuth: AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(System.Web.Http.Controllers.HttpActionContext actionContext)
{
if(actionContext.Request.Headers.Any(h=>h.Key.Equals("X-Requested-With",StringComparison.OrdinalIgnoreCase)))
{
var xhr = actionContext.Request.Headers.Single(h => h.Key.Equals("X-Requested-With", StringComparison.OrdinalIgnoreCase)).Value.First();
if (xhr.Equals("XMLHttpRequest", StringComparison.OrdinalIgnoreCase))
{
// this does not work either
//throw new HttpResponseException(HttpStatusCode.Unauthorized);
actionContext.Response = new System.Net.Http.HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized);
return;
}
}
base.HandleUnauthorizedRequest(actionContext);
}
}
Каким образом можно избежать этого поведения в ASP.NET Web API? Я смотрю, и я не мог найти способ сделать это.
С уважением.
PS: Я не могу поверить, что это 2012 год, и эта проблема все еще продолжается.
Ответы
Ответ 1
Замечания по выпуску для MVC 4 RC подразумевают, что это было устранено с момента использования бета-версии, которую вы используете?
http://www.asp.net/whitepapers/mvc4-release-notes
Несанкционированные запросы, обрабатываемые возвратом веб-API ASP.NET 401 Неавторизованный: неавторизованные запросы, обрабатываемые веб-API ASP.NET, теперь возвращают стандартный 401 неавторизованный ответ вместо перенаправления пользовательского агента на форму входа, так что ответ может обрабатываться клиентом Ajax.
В исходном коде для MVC появилась функциональность, добавленная через SuppressFormsAuthRedirectModule.cs
http://aspnetwebstack.codeplex.com/SourceControl/network/forks/BradWilson/AspNetWebStack/changeset/changes/ae1164a2e339#src%2fSystem.Web.Http.WebHost%2fHttpControllerHandler.cs.
internal static bool GetEnabled(NameValueCollection appSettings)
{
// anything but "false" will return true, which is the default behavior
Итак, похоже, что это включено по умолчанию, и RC должен исправить вашу проблему без каких-либо героев... в качестве побочного пункта похоже, что вы можете отключить этот новый модуль, используя AppSettings http://d.hatena.ne.jp/shiba-yan/20120430/1335787815:
<appSettings>
<Add Key = "webapi:EnableSuppressRedirect" value = "false" />
</appSettings>
Изменить (пример и пояснения)
Теперь я создал пример для этого подхода на GitHub. Новое подавление перенаправления требует использования двух правильных атрибутов "Авторизовать"; MVC Web [System.Web.Mvc.Authorize] и веб-API [System.Web.Http.Authorize] в контроллерах AND/OR в глобальных фильтрах Ссылка.
В этом примере, однако, излагается ограничение подхода. Похоже, что узлы "авторизации" в файле web.config всегда будут иметь приоритет над маршрутами MVC, например. config, подобный этому, переопределит ваши правила и будет перенаправлен на логин:
<system.web>
<authentication mode="Forms">
</authentication>
<authorization>
<deny users="?"/> //will deny anonymous users to all routes including WebApi
</authorization>
</system.web>
К сожалению, открытие этого для некоторых маршрутов URL с использованием элемента Location не работает, и вызовы WebApi будут продолжать перехватываться и перенаправляться на вход.
Решение
Для приложений MVC я просто предлагаю удалить конфигурацию из Web.Config и придерживаться глобальных фильтров и атрибутов в коде.
Если вы должны использовать узлы авторизации в Web.Config для MVC или иметь приложение Hybrid ASP.NET и WebApi, тогда @PilotBob - в комментариях ниже - обнаружил, что подпапки и несколько Web.Config могут использоваться для ваш торт и съесть его.
Ответ 2
Если кто-то заинтересован в решении одной и той же проблемы в приложении ASP.NET MVC с использованием атрибута Authorize:
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class Authorize2Attribute : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAuthenticated)
{
filterContext.Result = new HttpStatusCodeResult((int) HttpStatusCode.Forbidden);
}
else
{
if (filterContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.HttpContext.Response.SuppressFormsAuthenticationRedirect = true;
}
base.HandleUnauthorizedRequest(filterContext);
}
}
}
Таким образом, браузер правильно различает запрещенные и неавторизованные запросы.
Ответ 3
Мне удалось обойти анонимную настройку deny в web.config, установив следующее свойство:
Request.RequestContext.HttpContext.SkipAuthorization = true;
Я делаю это после некоторых проверок против объекта Request в методе Application_BeginRequest в Global.asax.cs, например, свойства RawURL и другой информации заголовка, чтобы убедиться, что запрос обращается к области, к которой я хочу разрешить анонимный доступ. Я все еще выполняю аутентификацию/авторизацию после вызова действия API.
