Al implementar su propio IUserStore, ¿son las interfaces "opcionales" en la clase realmente opcionales?

Estoy trabajando con Microsoft Asp.Net Identity Framework versión 2, y estoy implementando mi propio IUserStore. Mi nueva claseMyUserStore implementa elIUserStore<MyUserClass,int> interfaz y elIUserPasswordStore<MyUserClass,int>, que es lo que se requiere para usarlo con elUserManager<MyUserClass,int> clase. O al menos eso es lo que obtuve de la lectura de tutoriales comoesta:

"La única interfaz requerida en el sistema de identidad es IUserStore" - Scott Allen

Pero este no parece ser el caso cuando ejecuto el código.

Inicializo a mi gerente:

var uMan= new UserManager<MyUserClass, int>(new MyUserStore()); 
var sMan = new SignInManager<MyUserClass, int>(uMan,authCtxFromOwin);

Y cuando se ejecuta sMan.PasswordSignIn (...) en SignInManager, pase lo que pase, SignInManager siempre ejecuta una funcionalidad en UserManager que depende de las interfaces opcionales. Aquí está la fuente del método PasswordSignInAsync de la clase SignInManager:

public virtual async Task<SignInStatus> PasswordSignInAsync(string userName, string password, bool isPersistent, bool shouldLockout)
        {
           ...
            if (await UserManager.IsLockedOutAsync(user.Id).WithCurrentCulture())
            {
                return SignInStatus.LockedOut;
            }
            if (await UserManager.CheckPasswordAsync(user, password).WithCurrentCulture())
            {
                return await SignInOrTwoFactor(user, isPersistent).WithCurrentCulture();
            }
            ...
            return SignInStatus.Failure;
        }

Siempre llama a UserManager.IsLockedOutAsync () antes de intentar verificar la contraseña, por lo que si la tienda no implementa la interfaz IUserLockoutStore, se produce una excepción cada vez que pase lo que pase.

¿Esto significa que para usar la funcionalidad predeterminada de las clases UserManager y SignInManager, debe implementar todas las interfaces de I * Store?

Parece que la solución es heredar de SignInManager y anular el método PasswordSignInAsync. ¿Es esa la práctica habitual?

¡Gracias!

Respuestas a la pregunta(1)

Su respuesta a la pregunta