Запретить 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.