ASP.net Identity SecurityStampValidator OnValidateIdentity regenerateIdentity tham số

Question

Bất cứ ai có thể giải thích tại sao lớp ApplicationUser tạo ra chức năng trợ giúp sau?

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

Nơi duy nhất tôi có thể thấy nó đang được sử dụng là trong Startup.Auth.cs tập tin, như thông số regenerateIdentity gọi lại cho SecurityStampValidator.OnValidateEntity chức năng:

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

Như bạn có thể nhìn thấy từ người trợ giúp nó chỉ quay lại và gọi số manager.CreatedIdentityAsync. Có lý do nào mà họ "ô nhiễm" lớp ApplicationUser với phương pháp trợ giúp thay vì thiết lập OnValidateEntity như sau?

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

* ngồi biên tập cho rõ ràng và đơn giản

Bằng cách trừu tượng hóa các phương pháp nhận dạng thế hệ vào lớp người sử dụng, Chúng tôi đang cho phép một điểm mở rộng.

Hãy tưởng tượng một tình huống trong đó ứng dụng của bạn có nhiều loại người dùng khác nhau, mỗi loại sẽ có thể triển khai logic tái sinh của riêng mình mà không cần phải có các loại xác thực riêng biệt. Đi theo phương thức trợ giúp trong lớp con ApplicationUser của lớp cơ sở 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; 
    } 
} 

Bây giờ chúng ta có thể tách yêu cầu của chúng tôi vào lớp người dùng khác nhau mà không cần phải sửa đổi các đường ống dẫn xác thực OWIN, hoặc tạo một CookieAuthenticationProvider mới đối với từng loại đơn giản bằng cách subclassing IdentityUser cơ sở.

tldr;

Nó đẩy trách nhiệm tái tạo nhận dạng lên lớp người dùng đang được tạo lại. Tương tự như mẫu phương thức nhà máy.