Quando si crea un sito con i bit di identità installate, il sito avrà un file chiamato "IdentityModels.cs". In questo file è una classe denominata ApplicationUser che eredita da IdentityUser.
// You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more.
public class ApplicationUser : IdentityUser
C'è un bel link nei commenti lì, per la facilità cliccare here
Questo tutorial ti dice esattamente che cosa dovete fare per aggiungere proprietà personalizzate per l'utente.
E in realtà, non preoccupatevi nemmeno di guardare il tutorial.
1) aggiungere una proprietà alla classe ApplicationUser, ad esempio:
public bool? IsEnabled { get; set; }
2) aggiungere una colonna con lo stesso nome sul tavolo AspNetUsers nel vostro DB.
3) boom, il gioco è fatto!
Ora nel tuo AccountController, si hanno un'azione Registrati come segue:
public async Task<ActionResult> Register(RegisterViewModel model)
{
if (ModelState.IsValid)
{
var user = new ApplicationUser { UserName = model.Email, Email = model.Email, IsEnabled = true };
var result = await UserManager.CreateAsync(user, model.Password);
if (result.Succeeded)
ho aggiunto l'IsEnabled = true sulla creazione dell'oggetto ApplicationUser. Il valore verrà ora mantenuto nella nuova colonna nella tabella AspNetUsers.
Sarà quindi necessario gestire il controllo di questo valore come parte del processo di accesso, eseguendo l'override di PasswordSignInAsync in ApplicationSignInManager.
ho fatto come segue:
public override Task<SignInStatus> PasswordSignInAsync(string userName, string password, bool rememberMe, bool shouldLockout)
{
var user = UserManager.FindByEmailAsync(userName).Result;
if ((user.IsEnabled.HasValue && !user.IsEnabled.Value) || !user.IsEnabled.HasValue)
{
return Task.FromResult<SignInStatus>(SignInStatus.LockedOut);
}
return base.PasswordSignInAsync(userName, password, rememberMe, shouldLockout);
}
tua situazione potrebbe essere diversa, e non si può decidere di tornare che SignInStatus, ma si ottiene l'idea.
Come si ottiene lo stesso risultato in ASP.NET Core 1.0 con Identity 3.0 che non ha ApplicationSignInManager o PasswordSignInAsync (...)? – nam
L'uso di '.Result' è contro le raccomandazioni ed è noto che causa deadlock in alcuni scenari, inoltre blocca il thread che sconfigge l'intero punto di asincronia. Sarebbe preferibile contrassegnare il metodo 'PasswordSignInAsync' come' async' e attendere 'FindByEmailAsync'. – TKharaishvili
Il problema più grande con questo è se sono già registrati, non li riguarderà. In particolare se hanno selezionato la casella di controllo Ricordami. Se accedono regolarmente al sito, non avranno mai bisogno di accedere. Sto cercando di capire se è possibile utilizzare la logica di blocco esistente per questo, e se è meglio gestire gli utenti che hanno già effettuato l'accesso . –