IUserStore <TUser> .CreateAsync: come indicare un errore nell'implementazione personalizzata?

Question

Sto scrivendo un'implementazione personalizzata per IUserStore. La firma del metodo è creare:

public async virtual Task CreateAsync(TUser user) 

E che senso considerare l'interfaccia IUserStore core Microsoft.AspNet.Identity è (che è lo stesso).

Tuttavia l'interfaccia della classe UserManager definito in Microsoft.AspNet.Identity è:

public virtual Task<IdentityResult> CreateAsync(TUser user); 

Il mio problema è che non vedo come avrei dovuto passare questo IdentityResult al UserManager in quanto il tipo di ritorno in store è semplicemente "Task". Ho una logica personalizzata per determinare se un utente può o non può essere creato, quindi ho davvero bisogno di dire il risultato di CreateAsync all'UtilityManager.

Qualche idea?

Answer 1

Guardando il source code for UserManager.CreateAsync (questo è per Identity 2.0) si può vedere che prima di chiamare IUserStore.CreateAsync, si effettua una chiamata a IIdentityValidator<TUser>.ValidateAsync, che è responsabile di tornare in realtà il relativo IdentityResult oggetto:

public virtual async Task<IdentityResult> CreateAsync(TUser user) 
{ 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user).ConfigureAwait(false); 
     var result = await UserValidator.ValidateAsync(user).ConfigureAwait(false); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (UserLockoutEnabledByDefault && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true).ConfigureAwait(false); 
     } 
     await Store.CreateAsync(user).ConfigureAwait(false); 
     return IdentityResult.Success; 
} 

Il Lo scopo principale di IUserStore.CreateAsync è di effettuare la chiamata all'origine dati sottostante che salva i dati. Sembra che tu voglia effettivamente implementare IIdentityValidator<TUser> e impostarlo sull'istanza UserManager.

Answer 2

La risposta è in the source code, ecco una parte della realizzazione del UserManager al momento della scrittura:

public virtual async Task<IdentityResult> CreateAsync(TUser user, 
     CancellationToken cancellationToken = default(CancellationToken)) 
    { 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user, cancellationToken); 
     var result = await ValidateUserInternal(user, cancellationToken); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (Options.Lockout.EnabledByDefault && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true, cancellationToken); 
     } 
     await UpdateNormalizedUserNameAsync(user, cancellationToken); 
     await Store.CreateAsync(user, cancellationToken); 
     return IdentityResult.Success; 
    } 

Quindi, in pratica ritornano sempre vero. Ciò significa che nella versione corrente, l'inserimento dei controlli di creazione in UserStore va contro l'utilizzo previsto del framework.

Tuttavia ho notato che questo verrà modificato nella prossima versione. L'interfaccia IUserStore diventerà:

Task<IdentityResult> CreateAsync(TUser user, CancellationToken cancellationToken); 

e l'implementazione UserManager:

public virtual async Task<IdentityResult> CreateAsync(TUser user) 
    { 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user); 
     var result = await ValidateUserInternal(user); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (Options.Lockout.AllowedForNewUsers && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true, CancellationToken); 
     } 
     await UpdateNormalizedUserNameAsync(user); 
     await UpdateNormalizedEmailAsync(user); 

     return await Store.CreateAsync(user, CancellationToken); 
    } 

Quindi mettere la logica di creazione nella UserStore sarà possibile in quel momento. Questo sarà un modo migliore di progettare, secondo me, dal momento che il cliente non dovrebbe gestire i problemi di integrità.