¿Por qué la lógica de redirección returnUrl duplicada en las aplicaciones web de asp.net con owin/identity?

asp.net-mvc asp.net-identity

Question

Cuando crea una nueva aplicación web (ya sea webforms o mvc) en visual studio, existe una lógica de autenticación posterior que busca un parámetro ReturnUrl en la cadena de consulta y luego redirige al usuario allí si existe: In weforms - Login.aspx .cs tienes esto:

protected void LogIn(object sender, EventArgs e)
{
   ...
        switch (result)
        {
            case SignInStatus.Success:
                IdentityHelper.RedirectToReturnUrl(Request.QueryString["ReturnUrl"], Response);
                break;
            ...
        }
    }
}

En MVC - AccountController.cs tienes esto:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
   ...
    switch (result)
    {
        case SignInStatus.Success:
            return RedirectToLocal(returnUrl);
        ...
    }
}

Ahora, además, la configuración de Owin está configurada para usar la autenticación de cookies, que utiliza la clase Microsoft.Owin.Security.Cookies.CookieAuthenticationHandler, que a su vez busca un parámetro ReturnUrl y aplica una redirección si existe:

protected override async Task ApplyResponseGrantAsync()
{
    AuthenticationResponseGrant signin = Helper.LookupSignIn(Options.AuthenticationType);
    bool shouldSignin = signin != null;
    AuthenticationResponseRevoke signout = Helper.LookupSignOut(Options.AuthenticationType, Options.AuthenticationMode);
    bool shouldSignout = signout != null;

    if (shouldSignin || shouldSignout || _shouldRenew)
    {
        ...

        if ((shouldLoginRedirect || shouldLogoutRedirect) && Response.StatusCode == 200)
        {
            IReadableStringCollection query = Request.Query;
            string redirectUri = query.Get(Options.ReturnUrlParameter);
            if (!string.IsNullOrWhiteSpace(redirectUri)
                && IsHostRelative(redirectUri))
            {
                var redirectContext = new CookieApplyRedirectContext(Context, Options, redirectUri);
                Options.Provider.ApplyRedirect(redirectContext);
            }
        }
    }
}

Ambos redireccionamientos parecen ejecutarse durante la solicitud de inicio de sesión / autenticación. Uno se aplica en HttpContext.Response, y el otro se aplica en el contexto de redirección de Owin. En mi experiencia, parece que las últimas llamadas de redireccionamiento ganan, lo cual es un problema si tiene una lógica de redireccionamiento especial aplicada después del inicio de sesión en el código de su sitio web porque el redireccionamiento de Owin incorporado lo anula.

¿Hay una buena razón para esta lógica duplicada? ¿Es esto un diseño pobre? Entonces, si estoy usando la autenticación Owin Cookie de asp.net, ¿debería tener una lógica de código de redireccionamiento posterior al inicio de sesión en el controlador de cuenta o el código aspx? Y si es así, ¿debería aplicarse el redireccionamiento en HttpContext.Response o a través de Owin de alguna manera?

Answer 1

Como ha dicho, estas tres formas de redirigir todas pertenecen a partes diferentes: WebForms, MVC, OWIN. Cada uno de ellos puede ser usado independientemente del otro (OWIN en una situación de auto-alojamiento), por lo que existe la necesidad de hacer lo mismo en todos y cada uno de ellos.

Sin embargo, no estoy completamente seguro de por qué la última plantilla de MVC necesita RedirectToLocal . Me gustaría ir con la compatibilidad hacia atrás, este método ha estado allí durante mucho tiempo.

Además, el redireccionamiento OWIN no gana en MVC: en una de mis aplicaciones, siempre redirigiré al usuario según su función, incluso si hay un parámetro con una URL local a la que ir, mis usuarios siempre terminan en la página especificada en el controlador MVC .
Sin embargo, habiendo buscado el código fuente de OWIN y la lógica de redireccionamiento, parece extraño que MVC gane. Probablemente necesite pasar todo el camino hacia abajo y ver qué sucede en el escenario MVC.