Pregunta

Algunos antecedentes:Nuestro cliente quería que una serie de acciones volvieran a la acción anterior cuando estuvieran terminadas.Por ejemplo, si estaba en una vista de lista de objetos y hacía clic en el botón "crear nuevo objeto", quería volver a la vista de lista después de completar y guardar el formulario o después de cancelar la acción.Lo implementamos imitando el ReturnUrl comportamiento que se utiliza con intentos de acceso no autorizados (agregar la dirección actual como un parámetro de consulta codificado en URL).

El problema:Si no estoy autorizado (o en otras palabras, no he iniciado sesión) e intento acceder a una acción que lo requiere, se me redirige a la página de inicio de sesión (como debería) y se ingresa la URL actual. ReturnUrl parámetro.Sin embargo, cuando la dirección actual ya contiene ReturnUrl parámetro de consulta, no me redirigen a ninguna parte y en su lugar aparece una página en blanco.¿Hay alguna razón por la que esto sucede?

El resultado esperado sería ser redirigido a la pantalla de inicio de sesión con la (versión codificada en URL) de la URL actual colocada en el ReturnUrl parámetro (independientemente de si la URL actual contiene su propia ReturnUrl parámetro o no)

¿Hay alguna manera de hacer que funcione como se esperaba?Claro, en teoría podría cambiar el nombre del parámetro "ReturnUrl" (en mis propias acciones) a otro, pero ya usamos dicho parámetro en tantos lugares que cambiarles el nombre no será una tarea fácil.Además, en primer lugar, no entiendo realmente por qué esto no funciona.

PDEl problema sólo ocurre si nombro el parámetro ReturnUrl, si es returnUrl Todo funciona como deberia.


Editar:Esta pregunta se llamaba anteriormente:El acceso no autorizado a acciones restringidas no devuelve nada si la URL contiene un parámetro llamado ReturnUrl.Cambié el título para que sea más fácil de entender.


Editar:Esta pregunta podría ser un duplicado de La solicitud no autorizada no redirige a la página de inicio de sesión con el parámetro de cadena de consulta returnUrl.Tendré que investigar más a fondo si la solución proporcionada allí resuelve mi problema o no. Actualizar:La redacción es similar, pero el problema es diferente después de todo, por lo que no es un duplicado.

¿Fue útil?

Solución

Esto resultó ser un gran dolor de cabeza para solucionar, pero logré hacerlo.En la búsqueda para descubrir por qué falla la redirección para iniciar sesión en algunas URL, tuve que responderme a mí mismo una pregunta importante.¿Qué es realmente responsable de realizar la redirección y cómo puedo anularla?

Este El artículo me encaminó (el responsable de la redirección fue el [Authorize] filtro) y comencé a buscar una solución.Después de buscar un poco encontré este Filtro de autorización personalizado simple.Por supuesto, no hizo lo que quería de fábrica (y lo que quiero es básicamente que la autorización funcione normalmente pero que no se interrumpa en las URL que contienen ReturnUrl param), así que modifiqué el código y obtuve esto:

public class Authorize2 : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        // 1. Get the default login url that was declared in web.config
        string returnUrl = FormsAuthentication.LoginUrl;
        // 2. Append current url as a return url to the login url
        returnUrl += "?ReturnUrl=" + HttpUtility.UrlEncode(HttpContext.Current.Request.Url.PathAndQuery);
        // 3. ...
        // 4. Profit
        filterContext.Result = new RedirectResult(returnUrl);
    }
}

Después de escribir este fragmento de código, pasé otra hora tratando de descubrir por qué no funciona (puntos de interrupción dentro de HandleUnauthorizedRequest nunca fueron alcanzados).Entonces encontré este sitio y de repente tuvo sentido.Un colega mío agregó un global Authorize filtrar todas las acciones por cualquier motivo y a mi propio filtro personalizado nunca se le pidió que autorizara nada (\App_Start\FilterConfig.cs).Después de eliminar esa línea (eventualmente tendré que poner mi filtro personalizado en su lugar), el código anterior funcionó de maravilla.

En cierto modo, la pregunta aún está abierta, quiero decir, todavía es un misterio por qué la autorización falla en esas URL.La respuesta a esa pregunta reside sin duda en System.Web.Mvc.AuthorizeAttribute código fuente, pero por ahora estoy satisfecho con que funcione correctamente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top