ASP.net Identity SecurityStampValidator OnValidateIdentity regenerateIdentity parameter

Question

Qualcuno può spiegare perché la classe ApplicationUser crea la seguente funzione di supporto?

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

L'unico posto dove posso trovarlo in uso è nelle Startup.Auth.cs di file, come il parametro regenerateIdentity callback per la funzione SecurityStampValidator.OnValidateEntity:

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

Come si può vedere da l'aiutante si gira e chiama lo manager.CreatedIdentityAsync. C'è una ragione per cui hanno "inquinato" la classe ApplicationUser con il metodo helper invece di impostare OnValidateEntity come segue?

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 per chiarezza e semplicità

Astraendo il metodo Identity generazione nella classe utente, c'è consentito un punto di estensibilità.

Immaginate uno scenario in cui l'applicazione abbia diversi tipi di utenti, ognuno dei quali sarebbe in grado di implementare la propria logica di rigenerazione senza dover disporre di tipi di autenticazione separati. Utilizza il metodo helper nella sottoclasse ApplicationUser della classe base 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; 
    } 
} 

Possiamo ora separare le nostre rivendicazioni in diverse classi di utenti senza dover modificare l'autenticazione conduttura OWIN, oppure creare una nuova CookieAuthenticationProvider per ogni tipo semplicemente sottoclasse della IdentityUser base.

tldr;

Spinge le responsabilità di rigenerazione dell'identità sulla classe utente che viene rigenerata. Simile a un modello di metodo di fabbrica.