ASP.NET-Identität SecurityStampValidator OnValidateIdentity regenerateIdentity-Parameter

Question

Kann jemand erklären, warum die Klasse ApplicationUser die folgende Hilfsfunktion erstellt?

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

Der einzige Ort, wo ich es verwendet wird, finden Sie in den Startup.Auth.cs Datei als regenerateIdentity Callback-Parameter für die SecurityStampValidator.OnValidateEntity Funktion:

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

Wie Sie sehen können, Der Helfer dreht sich gerade um und ruft manager.CreatedIdentityAsync an. Gibt es einen Grund, warum sie die Klasse ApplicationUser mit der Hilfsmethode "verschmutzt" anstatt OnValidateEntity wie folgt einzurichten?

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 für Klarheit und Einfachheit

durch die Identität Generierung Methode in die Benutzerklasse zu abstrahieren, wir einen Punkt der Dehnbarkeit erlaubt.

Stellen Sie sich ein Szenario vor, in dem Ihre Anwendung mehrere verschiedene Benutzertypen hat, von denen jeder seine eigene Regenerierungslogik implementieren kann, ohne dass separate Authentifizierungstypen erforderlich sind. Verwenden Sie die Hilfsmethode in der ApplicationUser-Unterklasse der IdentityUser-Basisklasse.

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

Wir können jetzt unseren Ansprüchen in verschiedene Benutzerklassen trennen, ohne dass die Authentifizierungs OWIN Pipeline zu modifizieren oder einen neuen CookieAuthenticationProvider für jeden einfach durch Subklassen der Basis IdentityUser Typ erstellen.

tldr;

Die Verantwortlichkeiten für die Identitätsregenerierung werden auf die Benutzerklasse übertragen, die neu generiert wird. Ähnlich einem Fabrikmethodenmuster.