C'è qualche vantaggio nella memorizzazione delle informazioni dell'utente in AspNetUserClaims con Asp.Net Identity 2?

Question

Vorrei memorizzare ulteriori informazioni sull'utente. Da quello che ho capito ciò che segue è la solita opzione:

public class ApplicationUser : IdentityUser { 
     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; 
     } 
     public string FirstName { get; set; } 
     public string LastName { get; set; } 

    } 

Qui sono stati aggiunti il ​​FirstName e cognome e appariranno i campi come aggiuntive nella tabella AspNetUsers.

Tuttavia sembra che ora con Asp.Net Identity ci sia anche un'opzione per memorizzare questo tipo di informazioni nella tabella AspNetUserClaims.

Qualcuno può spiegarmi. Andando avanti è questo il tipo di informazioni che potrebbero essere archiviate in AspNetUserClaims. Se è così allora qualcuno ha qualche esempio di questo.

Answer 1

Alla fine della giornata, l'utente che ha effettuato l'accesso verrà convertito in una serie di attestazioni memorizzate in ClaimsIdentity che rappresenta l'utente in HttpContext.User.Identity. Puoi scegliere di memorizzare FirstName/LastName come colonne nella tabella utente che puoi quindi esplicitamente leggere e convertire nelle attestazioni appropriate (se lo desideri), oppure puoi memorizzarle direttamente come attestazioni nella tabella AspnetUserClaims (che è solo memorizzarle come due colonne di stringhe) che per impostazione predefinita verranno automaticamente aggiunte all'identità dei sinistri dell'utente. Entrambi i metodi sono però più o meno equivalenti, quindi si tratta di preferenze personali.

BTW l'unica ragione per cui si desidera che siano nel ClaimsIdentity dell'utente è se si desidera salvare un hit db solo per visualizzare il nome e utilizzare sempre le attestazioni FirstName/LastName in ClaimsIdentity. Se si recupera l'utente e si utilizza user.FirstName, non c'è molto valore nel generare anche le attestazioni sui nomi.

Answer 2

Oltre a @Hao Kung, quando i reclami saranno più lunghi di quanto consentito Cookie capacità del browser, le informazioni sulle richieste potrebbero essere ritagliate.

Secondo Thinktecture Identity Server article, una delle famose alternative di default AspNet Identity, ha detto come di seguito.

Una volta che l'applicazione diventa complessa, lo è anche il numero di richieste da gestire. Per impostazione predefinita, tutti i reclami sono memorizzati come parte del cookie di sessione e browser come Safari impongono una restrizione sulle dimensioni del cookie. Quindi, un bel giorno, quando aggiungerai altre richieste all'applicazione, inizierai a ricevere errori di serializzazione. Questo perché solo il cookie parziale verrà rispedito al server e il server non sa cosa fare con esso. Quindi la soluzione per questo problema è creare il token di sicurezza nella modalità "Reference". Significa memorizzare il token sul server e memorizzare un ID di sessione di riferimento come cookie. Guarda l'immagine qui sotto. La dimensione del cookie è di pochi byte: