Chamada webapi não autorizada retornando página de login em vez de 401

Como configuro meu projeto mvc / webapi para que um método webapi chamado de uma exibição de navalha não retorne a página de login quando ela não é autorizada?

É um aplicativo MVC5 que também possui controladores WebApi para chamadas via javascript.

Os dois métodos abaixo

[Route("api/home/LatestProblems")]      
[HttpGet()]
public List<vmLatestProblems> LatestProblems()
{
    // Something here
}

[Route("api/home/myLatestProblems")]
[HttpGet()]
[Authorize(Roles = "Member")]
public List<vmLatestProblems> mylatestproblems()
{
   // Something there
}

são chamados pelo seguinte código angular:

angular.module('appWorship').controller('latest', 
    ['$scope', '$http', function ($scope,$http) {         
        var urlBase = baseurl + '/api/home/LatestProblems';
        $http.get(urlBase).success(function (data) {
            $scope.data = data;
        }).error(function (data) {
            console.log(data);
        });
        $http.get(baseurl + '/api/home/mylatestproblems')
          .success(function (data) {
            $scope.data2 = data;
        }).error(function (data) {
            console.log(data);
        });  
    }]
);

Portanto, não estou logado e o primeiro método retorna dados com êxito. o segundo método retorna (na função de sucesso) dados que contêm o equivalente a uma página de login. ou seja, o que você obteria no mvc se solicitasse uma ação do controlador que estivesse estampada com [Autorizar] e você não estivesse logado.

Quero que ele retorne um 401 não autorizado, para que eu possa exibir dados diferentes para os usuários com base em se eles estão conectados ou não. Idealmente, se o usuário estiver conectado, desejo poder acessar a propriedade User do Controlador para que eu possa retornar dados específicos para esse Membro.

ATUALIZAÇÃO: Como nenhuma das sugestões abaixo parece funcionar mais (alterações em Identity ou WebAPI), criei um exemplo bruto no github que deve ilustrar o problema.

Existem duas implementações AuthorizeAttribute e você precisa se referir à correta para APIs da Web. Há System.Web.Http.AuthorizeAttribute que é usado para APIs da Web e System.Web.Mvc.AuthorizeAttribute que é usado para controladores com exibições. Http.AuthorizeAttribute retornará um erro 401 se a autorização falhar e o Mvc.AuthorizeAttribute será redirecionado para a página de logon.

Atualizado 26/11/2013

Parece que as coisas mudaram drasticamente com o MVC 5, como Brock Allen apontou em seu artigo . Eu acho que o pipeline OWIN assume e introduz algum novo comportamento. Agora, quando o usuário não está autorizado, um status 200 é retornado com as seguintes informações no cabeçalho HTTP.

X-Responded-JSON: {"status":401,"headers":{"location":"http:\/\/localhost:59540\/Account\/Login?ReturnUrl=%2Fapi%2FTestBasic"}}

Você pode alterar sua lógica no lado do cliente para verificar essas informações no cabeçalho para determinar como lidar com isso, em vez de procurar um status 401 na ramificação de erro.

Eu tentei substituir esse comportamento em um costume AuthorizeAttribute , definindo o status na resposta nos OnAuthorization e HandleUnauthorizedRequest métodos.

actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized);

Mas isso não funcionou. O novo pipeline deve pegar essa resposta mais tarde e modificá-la para a mesma resposta que eu estava recebendo antes. Lançar uma HttpException também não funcionou, pois acabou de mudar para um status de erro 500.

Testei a solução de Brock Allen e funcionou quando estava usando uma chamada de jQuery ajax. Se não está funcionando para você, acho que é porque você está usando angular. Execute seu teste com o Fiddler e veja se o seguinte está no seu cabeçalho.

X-Requested-With: XMLHttpRequest

Se não for, então esse é o problema. Eu não estou familiarizado com angular, mas se ele permitir que você insira seus próprios valores de cabeçalho, adicione-o às suas solicitações de ajax e provavelmente começará a funcionar.

Brock Allen tem um bom post sobre como retornar 401 para chamadas ajax ao usar autenticação de cookie e OWIN. http://brockallen.com/2013/10/27/using-cookie-authentication-middleware-with-web-api-and-401-response-codes/

Coloque isso no método ConfigureAuth no arquivo Startup.Auth.cs:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
  AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
  LoginPath = new PathString("/Account/Login"),
  Provider = new CookieAuthenticationProvider
  {
    OnApplyRedirect = ctx =>
    {
      if (!IsAjaxRequest(ctx.Request))
      {
        ctx.Response.Redirect(ctx.RedirectUri);
      }
    }
  }
});

private static bool IsAjaxRequest(IOwinRequest request)
{
  IReadableStringCollection query = request.Query;
  if ((query != null) && (query["X-Requested-With"] == "XMLHttpRequest"))
  {
     return true;
  }
  IHeaderDictionary headers = request.Headers;
  return ((headers != null) && (headers["X-Requested-With"] == "XMLHttpRequest"));
}

Se você estiver adicionando WebApi do asp.net no site MVC do asp.net, provavelmente desejará responder não autorizado a algumas solicitações. Mas a infraestrutura do ASP.NET entra em jogo e, quando você tenta definir o código de status da resposta como HttpStatusCode.Unauthorized, você recebe o redirecionamento 302 para a página de login.

Se você estiver usando a identidade asp.net e a autenticação baseada em owin aqui, um código que pode ajudar a resolver esse problema:

public void ConfigureAuth(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
        LoginPath = new PathString("/Account/Login"),
        Provider = new CookieAuthenticationProvider()
        {
            OnApplyRedirect = ctx =>
            {
                if (!IsApiRequest(ctx.Request))
                {
                    ctx.Response.Redirect(ctx.RedirectUri);
                }
            }
        }
    });

    app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
}


private static bool IsApiRequest(IOwinRequest request)
{
    string apiPath = VirtualPathUtility.ToAbsolute("~/api/");
    return request.Uri.LocalPath.StartsWith(apiPath);
}

Eu tenho a mesma situação quando o OWIN sempre redireciona a resposta 401 para a página de login da WebApi. Nossa API da Web suporta não apenas chamadas ajax de Angular, mas também chamadas móveis, Win Form. Portanto, a solução para verificar se a solicitação é ajax não está realmente classificada para o nosso caso.

Suppress-RedirectOptei por outra abordagem: injetar uma nova resposta de cabeçalho: se as respostas vierem do webApi. A implementação está no manipulador:

public class SuppressRedirectHandler : DelegatingHandler
{
    /// <summary>
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        return base.SendAsync(request, cancellationToken).ContinueWith(task =>
        {
            var response = task.Result;
            response.Headers.Add("Suppress-Redirect", "True");
            return response;
        }, cancellationToken);
    }
}

E registre esse manipulador no nível global da WebApi:

config.MessageHandlers.Add(new SuppressRedirectHandler());

Portanto, na inicialização do OWIN, você pode verificar se o cabeçalho de resposta possui Suppress-Redirect:

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationMode = AuthenticationMode.Active,
        AuthenticationType = DefaultApplicationTypes.ApplicationCookie,
        ExpireTimeSpan = TimeSpan.FromMinutes(48),

        LoginPath = new PathString("/NewAccount/LogOn"),

        Provider = new CookieAuthenticationProvider()
        {
            OnApplyRedirect = ctx =>
            {
                var response = ctx.Response;
                if (!IsApiResponse(ctx.Response))
                {
                    response.Redirect(ctx.RedirectUri);
                }
            }
        }
    });
}

private static bool IsApiResponse(IOwinResponse response)
{
    var responseHeader = response.Headers;

    if (responseHeader == null) 
        return false;

    if (!responseHeader.ContainsKey("Suppress-Redirect"))
        return false;

    if (!bool.TryParse(responseHeader["Suppress-Redirect"], out bool suppressRedirect))
        return false;

    return suppressRedirect;
}

Nas versões anteriores do ASP.NET, você precisava fazer várias coisas para fazer isso funcionar.

A boa notícia é que você está usando o ASP.NET 4.5. você pode desativar o redirecionamento da autenticação de formulários usando o novo propriedade HttpResponse.SuppressFormsAuthenticationRedirect .

Em Global.asax:

protected void Application_EndRequest(Object sender, EventArgs e)
{
        HttpApplication context = (HttpApplication)sender;
        context.Response.SuppressFormsAuthenticationRedirect = true;
}

EDIT : você também pode querer dar uma olhada neste artigo de Sergey Zwezdin, que tem uma maneira mais refinada de realizar o que você está tentando fazer.

Trechos de código relevantes e narração do autor colados abaixo. Autor original do código e narração - Sergey Zwezdin .

Primeiro - vamos determinar se a solicitação HTTP atual é uma solicitação AJAX. Se sim, devemos desativar a substituição do HTTP 401 pelo HTTP 302:

public class ApplicationAuthorizeAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        var httpContext = filterContext.HttpContext;
        var request = httpContext.Request;
        var response = httpContext.Response;

        if (request.IsAjaxRequest())
            response.SuppressFormsAuthenticationRedirect = true;

        base.HandleUnauthorizedRequest(filterContext);
    }
}

Segundo - vamos adicionar uma condição :: se o usuário for autenticado, enviaremos HTTP 403; e HTTP 401 caso contrário.

public class ApplicationAuthorizeAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        var httpContext = filterContext.HttpContext;
        var request = httpContext.Request;
        var response = httpContext.Response;
        var user = httpContext.User;

        if (request.IsAjaxRequest())
        {
            if (user.Identity.IsAuthenticated == false)
                response.StatusCode = (int)HttpStatusCode.Unauthorized;
            else
                response.StatusCode = (int)HttpStatusCode.Forbidden;

            response.SuppressFormsAuthenticationRedirect = true;
            response.End();
        }

        base.HandleUnauthorizedRequest(filterContext);
    }
}

Bem feito. Agora devemos substituir todos os usos do AuthorizeAttribute padrão por esse novo filtro. Pode não ser aplicável para sime guys, que é um esteta de código. Mas não conheço outra maneira. Se você tiver, vamos aos comentários, por favor.

O último, o que devemos fazer - adicionar o tratamento HTTP 401/403 no lado do cliente. Podemos usar ajaxError no jQuery para evitar duplicação de código:

$(document).ajaxError(function (e, xhr) {
    if (xhr.status == 401)
        window.location = "/Account/Login";
    else if (xhr.status == 403)
        alert("You have no enough permissions to request this resource.");
});

O resultado -

• Se o usuário não estiver autenticado, ele será redirecionado para uma página de login após qualquer chamada AJAX.
• Se o usuário estiver autenticado, mas não tiver permissões suficientes, ele verá uma mensagem de erro amigável.
• Se o usuário estiver autenticado e tiver permissões suficientes, não haverá erros e a solicitação HTTP será prosseguida normalmente.

Se você estiver executando o seu Web APIde dentro do seu MVCprojeto, precisará criar um personalizado AuthorizeAttributepara aplicar aos seus APImétodos. Dentro do arquivo, IsAuthorized overridevocê precisa pegar a corrente HttpContextpara impedir o redirecionamento, assim:

    protected override bool IsAuthorized(HttpActionContext actionContext)
    {
        if (string.IsNullOrWhiteSpace(Thread.CurrentPrincipal.Identity.Name))
        {
            var response = HttpContext.Current.Response;
            response.SuppressFormsAuthenticationRedirect = true;
            response.StatusCode = (int)System.Net.HttpStatusCode.Forbidden;
            response.End();
        }

        return base.IsAuthorized(actionContext);
    }

Usando a integração do Azure Active Directory, a abordagem do CookieAuthenticationmiddleware não funcionou para mim. Eu tive que fazer o seguinte:

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions
    {
        ...
        Notifications = new OpenIdConnectAuthenticationNotifications
        {   
            ...         
            RedirectToIdentityProvider = async context =>
            {
                if (!context.Request.Accept.Contains("html"))
                {
                    context.HandleResponse();
                }
            },
            ...
        }
    });

Se a solicitação vier do próprio navegador (e não uma chamada AJAX, por exemplo), o cabeçalho Accept conterá a string html em algum lugar. Somente quando o cliente aceitar HTML, considerarei um redirecionamento algo útil.

Meu aplicativo cliente pode lidar com o 401 informando ao usuário que o aplicativo não tem mais acesso e precisa recarregar para fazer login novamente.

Eu também tinha um aplicativo MVC5 (System.Web) com WebApi (usando OWIN) e só queria impedir que 401 respostas do WebApi fossem alteradas para 302 respostas.

O que funcionou para mim foi criar uma versão personalizada do WebApi AuthorizeAttribute assim:

public class MyAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
    {
        base.HandleUnauthorizedRequest(actionContext);
        HttpContext.Current.Response.SuppressFormsAuthenticationRedirect = true;
    }
}

E para usá-lo no lugar do WebApi AuthorizeAttribute padrão. Usei o MVC AuthorizeAttribute padrão para manter o comportamento do MVC inalterado.

Basta instalar seguindo o Pacote NeGet

Pacote de instalação Microsoft.AspNet.WebApi.Owin

Escreva o seguinte código no arquivo WebApiConfig.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        //Web API configuration and services
        //Configure Web API to use only bearer token authentication.
        config.SuppressDefaultHostAuthentication();
        config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{action}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
        config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
        config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("multipart/form-data"));
    }
}

se você deseja capturar Content-Type == application / json, pode usar esse código:

private static bool IsAjaxRequest(IOwinRequest request)
    {
        IReadableStringCollection queryXML = request.Query;
        if ((queryXML != null) && (queryXML["X-Requested-With"] == "XMLHttpRequest"))
        {
            return true;
        }

        IReadableStringCollection queryJSON = request.Query;
        if ((queryJSON != null) && (queryJSON["Content-Type"] == "application/json"))
        {
            return true;
        }

        IHeaderDictionary headersXML = request.Headers;
        var isAjax = ((headersXML != null) && (headersXML["X-Requested-With"] == "XMLHttpRequest"));

        IHeaderDictionary headers = request.Headers;
        var isJson = ((headers != null) && (headers["Content-Type"] == "application/json"));

        return isAjax || isJson;

    }

Saudações!!

Eu estava com dificuldade para obter o código de status e uma resposta de texto trabalhando nos métodos OnAuthorization / HandleUnauthorizedRequest. Essa acabou sendo a melhor solução para mim:

    actionContext.Response = new HttpResponseMessage()
    {
        StatusCode = HttpStatusCode.Forbidden,
        Content = new StringContent(unauthorizedMessage)
    };

Após muita confusão tentando evitar os redirecionamentos para a página de login, percebi que isso é realmente bastante apropriado para o atributo Autorizar. Está dizendo vá e obtenha autorização. Em vez disso, para chamadas da API que não são autorizadas, eu só queria não revelar nenhuma informação a hackers. Esse objetivo foi mais fácil de alcançar diretamente, adicionando um novo atributo derivado de Authorize, que oculta o conteúdo como um erro 404:

public class HideFromAnonymousUsersAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
    {
         actionContext.Response = ActionContext.Request.CreateErrorResponse(HttpStatusCode.NotFound, "Access Restricted");
    }
}

Misturando MVC e WebAPI, se a solicitação não for autorizada, ele será redirecionado para a página de login, mesmo na solicitação WebAPI também. Para isso, podemos adicionar o código abaixo para enviar uma resposta ao aplicativo móvel

protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
{
    var httpContext = HttpContext.Current;
    if (httpContext == null)
    {
        base.HandleUnauthorizedRequest(actionContext);
        return;
    }

    actionContext.Response = httpContext.User.Identity.IsAuthenticated == false ?
        actionContext.Request.CreateErrorResponse(
      System.Net.HttpStatusCode.Unauthorized, "Unauthorized") :
       actionContext.Request.CreateErrorResponse(
      System.Net.HttpStatusCode.Forbidden, "Forbidden");

    httpContext.Response.SuppressFormsAuthenticationRedirect = true;
    httpContext.Response.End();
}

Obrigado rapazes!

No meu caso, combinei as respostas de cuongle e Shiva e obtive algo parecido com isto:

No manipulador OnException () do controlador para exceções da API:

filterContext.ExceptionHandled = true;
//...
var response = filterContext.HttpContext.Response;
response.Headers.Add("Suppress-Redirect", "true");
response.SuppressFormsAuthenticationRedirect = true;

No código de configuração de inicialização do aplicativo:

app.UseCookieAuthentication(new CookieAuthenticationOptions {
        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
        LoginPath = new PathString("/Account/Login"),
        Provider = new CookieAuthenticationProvider {
            OnValidateIdentity = ctx => {
                return validateFn.Invoke(ctx);
            },
            OnApplyRedirect = ctx =>
            {
                bool enableRedir = true;
                if (ctx.Response != null)
                {
                    string respType = ctx.Response.ContentType;
                    string suppress = ctx.Response.Headers["Suppress-Redirect"];
                    if (respType != null)
                    {
                        Regex rx = new Regex("^application\\/json(;(.*))?$",
                            RegexOptions.IgnoreCase);
                        if (rx.IsMatch(respType))
                        {
                            enableRedir = false;
                        }  
                    }
                    if ((!String.IsNullOrEmpty(suppress)) && (Boolean.Parse(suppress)))
                    {
                        enableRedir = false;
                    }
                }
                if (enableRedir)
                {
                    ctx.Response.Redirect(ctx.RedirectUri);
                }
            }
        }
    });

No MVC 5 com o Dot Net Framework 4.5.2, estamos obtendo "application / json, texto de reclamação .." no cabeçalho "Aceitar" Será bom usar o seguinte:

isJson = headers["Content-Type"] == "application/json" || headers["Accept"].IndexOf("application/json", System.StringComparison.CurrentCultureIgnoreCase) >= 0;