ASP.net Identity SecurityStampValidator Parametr OnValidateIdentity regenerateIdentity

Question

Czy ktoś może wyjaśnić, dlaczego klasa ApplicationUser tworzy następującą funkcję pomocnika?

public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<User, int> manager) 
{ 
    // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType 
    var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 
    // Add custom user claims here 
    return userIdentity; 
} 

Jedyne miejsce znajdę to wykorzystywane jest w Startup.Auth.cs plików jako parametr regenerateIdentity zwrotnego dla funkcji SecurityStampValidator.OnValidateEntity:

OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, User, int>(
    validateInterval: TimeSpan.FromSeconds(15), 
    regenerateIdentityCallback: (manager, user) => user.GenerateUserIdentityAsync(manager), 
    getUserIdCallback: (id) => id.GetUserId<int>()) 

Jak widać z pomocnik, który się odwraca i dzwoni pod numer manager.CreatedIdentityAsync. Czy istnieje powód, dla którego "zanieczyszczają" klasę ApplicationUser przy pomocy metody pomocniczej zamiast konfigurowania OnValidateEntity w następujący sposób?

OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, User, int>(
    validateInterval: TimeSpan.FromSeconds(15), 
    regenerateIdentityCallback: (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie), 
    getUserIdCallback: (id) => id.GetUserId<int>()) 

Answer 1

* editted dla jasności i prostoty

Według abstrahując metodę Identity Generation do klasy użytkownika Wolno nam punkt rozciągliwość.

Wyobraź sobie scenariusz, w którym Twoja aplikacja ma kilka różnych typów użytkowników, a każdy z nich może implementować własną logikę regeneracji bez konieczności posiadania oddzielnych typów uwierzytelniania. Zastosuj metodę pomocniczą w podklasie ApplicationUser klasy bazowej IdentityUser.

public class ApplicationUser : IdentityUser 
{  
    public string NickName {get; set; } 
    public DateTime BirthDay {get; set;} 


    public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager) 
    { 
     // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType 
     var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 
     // Add custom user claims here 
     return userIdentity; 
    } 
} 

Możemy teraz oddzielić nasze roszczenia do różnych klas użytkowników bez konieczności modyfikowania uwierzytelniania rurociągu OWIN lub utworzyć nowy CookieAuthenticationProvider dla każdego typu po prostu przez instacji IdentityUser bazową.

tldr;

Przesuwa odpowiedzialność za regenerację tożsamości do klasy użytkownika, która jest odtwarzana. Podobny do fabrycznego wzorca metody.