json - restablecer - quitar ventanas ancladas windows 10

¿Cómo puede mvc devolver código no autorizado sin redirigir a la vista de Inicio de sesión?

Question

Mi aplicación web MVC sirve a dos tipos de usuarios.

• Primero uno sobre el navegador web estándar;
• El segundo sobre REST devolviendo solo datos JSON.

Adicionalmente,

• Ambos requieren autenticación y autorización;
• Ambos escenarios se diferencian en función de la ruta para que sepa qué contenido servir.

Cuando los usuarios acceden a la aplicación, si no han iniciado sesión, la aplicación debería reaccionar de manera diferente.

1. En el primer caso, debería devolver la página de inicio de sesión predeterminada (esto está bien).
2. En el segundo caso, debe devolver un código 401 no autorizado solamente.

Estoy acostumbrado a trabajar con el servicio REST de WCF donde podría generar una excepción como esta:

throw new WebProtocolException(System.Net.HttpStatusCode.Unauthorized, exc.Message, exc);

y recibe un mensaje 401. El problema con el mismo enfoque dentro de MVC cuando coloco el statusCode esta manera:

HttpContext.Response.StatusCode = (Int32)HttpStatusCode.Unauthorized

siempre redirige a la página de inicio de sesión.

¿Cómo puedo hacer esto?

He intentado anular el AuthorizeAttribute y manejar la función OnAuthorization , pero de todos modos, tan pronto como configuro el statusCode de statusCode en 401, se redirige a la página statusCode de statusCode .

Answer 1

De esta forma logré evitar el redireccionamiento a la página de inicio de sesión.

En mi caso cuando quería recibir el código de estado para poder manejarlo en javascript:

protected void Application_EndRequest()
{
if (Context.Response.StatusCode == 302 && Context.Request.Headers["X-Requested-With"] == "XMLHttpRequest")
{
Context.Response.Clear();
Context.Response.StatusCode = 401;
}
}

Answer 2

Estoy trabajando en una aplicación web que también expone una API web y no veo este comportamiento.

Cuando está utilizando REST, necesita un mecanismo para autenticar al usuario que emite la solicitud para aquellos puntos finales / recursos que no son públicos.

Este mecanismo puede ser:

• Enviando sus credenciales con cada solicitud. Por lo general, utiliza la autenticación básica HTTP.
• Exponga un punto final de autenticación que pueda alcanzarse una vez con las credenciales adecuadas, y el usuario obtiene un token / ticket como resultado, si la autenticación se realiza correctamente.

Si opta por la segunda opción, existen alternativas de lo simple a lo complejo que harían que su solución sea más o menos robusta. El camino de Amazon es bien conocido y debidamente documentado. Sin embargo, a veces, solo devolver el token como encabezado usando https es suficiente si sus datos no son tan confidenciales.

Independientemente de si está utilizando la Autenticación HTTP básica o el mecanismo de autenticación más seguro del mundo, necesitará algo que valide lo que envía en cada solicitud y rellene el Principal en el contexto de la solicitud.

Este algo se puede lograr en Asp.net Web Api con un manejador de mensajes, también conocido como DelegatingHandler, que se encargará y procesará cada solicitud a los controladores de su API y poblará su Principal o no, según la información de autenticación que encuentre.

Puede encontrar un ejemplo de una implementación de DelegatingHandler here

Una vez que haya implementado esta infraestructura, debería poder utilizar Syste.Web.Http.AuthorizeAttribute aka [Autorizar] en el nivel de controlador de API o en el nivel de acción, de acuerdo con sus necesidades.

Debería obtener una redirección 401 no autorizada o no , si DelegingHandler no puede completar el principal dada la información de autenticación que tiene a mano.

No olvide registrar su DelegatingHandler en App_Start.

Answer 3

Lo que estás experimentando es un agujero en ASP.NET MVC (espero que se solucione algún día).

El modelo operativo estándar para ASP.NET es que si se detecta un código de estado 401 Http, a medida que lo experimenta, se redirige automáticamente a la página de inicio de sesión, y esto sucede incluso si ha ingresado a través de una llamada Ajax. Lamentablemente tampoco he encontrado ninguna forma de cambiar este comportamiento.

Lo que hago en cambio es devolver una alternativa, de lo contrario no se utiliza el código de estado de HTTP que puedo detectar en el cliente y manejar de la manera adecuada.

Por lo tanto, dentro de mi Filtro de autenticación, si es una solicitud de Ajax, devuelvo 449, de lo contrario, el estándar 401. Luego, en el cliente puedo examinar el XMLHttpRequest.status y tomar la acción apropiada si se detecta 449.

Answer 4

Para evitar la redirección de la página de inicio de sesión, debe establecer la propiedad SuppressFormsAuthenticationRedirect de HttpContext.Response en true;

 HttpContext.Response.SuppressFormsAuthenticationRedirect = true;

Answer 5

Puede crear un filtro de atributos de autorización simple (extender la clase AuthorizeAttribute) y usarlo para su control de acceso. Entonces intente algo como esto:

protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAjaxRequest() || string.Compare("GET", filterContext.HttpContext.Request.HttpMethod, true) != 0)
{
// Returns 403.
filterContext.Result = new HttpStatusCodeResult((int)HttpStatusCode.Forbidden);
}
else
{
// Returns 401.
filterContext.Result = new HttpUnauthorizedResult();
}
}

El efecto es que, las solicitudes POST y AJAX siempre recibirán una respuesta 403 que le facilita el manejo de sus envíos ajax en javascript. En cuanto a las publicaciones que no son ajax, en realidad no importa cuál sea la respuesta, ya que su usuario no debería haber tenido en sus manos el formulario de envío en primer lugar :)

En cuanto a las otras solicitudes, el método devuelve 401 que el módulo formsAuthentiction recogerá y luego redireccionará su respuesta a la página de inicio de sesión.

Answer 6

Puede utilizar el método OnRedirectToLogin mientras configura la identidad.