dlaczego powielona logika przekierowania returnUrl w aplikacjach internetowych asp.net z owin/identity?

Question

Po utworzeniu nowej aplikacji internetowej (albo webforms lub mvc) w wizualnym studio, jest logika post-uwierzytelniania, która sprawdza parametr ReturnUrl w ciągu zapytania, a następnie przekierowuje użytkownika, jeśli istnieje: Weforms - Login.aspx.cs masz to:

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

w MVC - AccountController.cs masz to:

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

teraz dodatkowo konfiguracja Owin jest skonfigurowany do korzystania z uwierzytelniania cookie, który używa Microsoft.Owin.Security.Cookies.CookieAuthenticationHandler klasa, która sama w sobie che CKS dla parametru ReturnURL i dotyczy przekierowanie jeśli istnieje:

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); 
      } 
     } 
    } 
} 

Oba przekierowania wydają się wykonać podczas wniosek logowanie/uwierzytelniania. Jeden jest stosowany w HttpContext.Response, a drugi jest stosowany w kontekście przekierowania Owin. Z mojego doświadczenia wynika, że ​​to ostatnie przekierowanie wygrywa, co jest problemem, jeśli masz specjalną logikę przekierowania zastosowaną po zalogowaniu w kodzie witryny, ponieważ zostanie ona przesłonięta przez wbudowane przekierowanie Owin.

Czy istnieje powód dla tej powielonej logiki? Czy to po prostu kiepski projekt? Więc jeśli używam asp.net Owin CookieAuthentication, czy powinienem mieć logikę przekierowania kodu po zalogowaniu na kontrolerze konta lub kod aspx? A jeśli tak, czy przekierowanie powinno być jakoś zastosowane w HttpContext.Response lub przez Owin?

Answer 1

Tak jak powiedziałeś, te trzy sposoby przekierowania wszystkich należą do różnych części: WebForms, MVC, OWIN. Każdy z nich może być używany niezależnie od drugiego (OWIN w sytuacji samo-hostingu), więc istnieje potrzeba zrobienia tego samego w każdym z nich.

Jednak nie jestem do końca pewien, dlaczego najnowszy szablon MVC potrzebuje RedirectToLocal. Poszedłem z kompatybilnością wsteczną - ta metoda była tam od wieków.

Również przekierowanie OWIN nie wygrywa w MVC - w jednej z moich aplikacji zawsze przekierowuję użytkownika w zależności od jego roli, nawet jeśli jest parametr z lokalnym adresem URL, moi użytkownicy zawsze trafiają na stronę określone w kontrolerze MVC.
Jednak po przejrzeniu kodu źródłowego OWIN i logiki przekierowania wydaje się dziwne, że MVC wygrywa. Prawdopodobnie trzeba przejść przez całą drogę w dół i zobaczyć, co dzieje się w scenariuszu MVC.