Shazwazza / UmbracoIdentity

ASP.NET Identity implementation for Umbraco's native member data
MIT License
111 stars 58 forks source link

Custom hasher not being used on backoffice #129

Closed skartknet closed 3 years ago

skartknet commented 3 years ago

We have this site that has been working fine with UmbracoIdentity. Members were created from the frontend.

Now the client has realised that when they create a new member in the backoffice they cannot log in from the frontend.

I have reviewed all the OWIN configuration and everything seems fine. What I think it's failing is a custom hasher configured in a custom user manager we are using.

The hasher is hit when the member tries to log in from the frontend but it fails to verify. When I create a member from the backoffice it doesn't hit the hasher, so it looks to me that here's is the problem. Any ideas why that is not hit? Am I missing some configuration?

thanks.

skartknet commented 3 years ago

UPDATE: I have set up the custom user manager with the hasher that comes with UmbracoIdentity and it works, so that's definitely the problem, but why?

So I have replaced this line: manager.PasswordHasher = new PasswordHasher();

with UmbracoIdentity's: manager.PasswordHasher = new MembershipPasswordHasher(provider);

My custom PassworHasher:

public class PasswordHasher : IPasswordHasher
    {
        /// <summary>Hash a password</summary>
        /// <param name="password"></param>
        /// <returns></returns>
        public virtual string HashPassword(string password)
        {
            return Crypto.HashPassword(password);
        }

        /// <summary>Verify that a password matches the hashedPassword</summary>
        /// <param name="hashedPassword"></param>
        /// <param name="providedPassword"></param>
        /// <returns></returns>
        public virtual PasswordVerificationResult VerifyHashedPassword(
            string hashedPassword,
            string providedPassword)
        {
            return Crypto.VerifyHashedPassword(hashedPassword, providedPassword) ? PasswordVerificationResult.Success : PasswordVerificationResult.Failed;
        }
    }
Shazwazza commented 3 years ago

What I think it's failing is a custom hasher configured in a custom user manager we are using.

Can you post some code of what changes you have made that deviate from the default install for this?

Shazwazza commented 3 years ago

This is where that is set by default https://github.com/Shazwazza/UmbracoIdentity/blob/e8d2ee805a9cb3cb11b7cfd6bcb590ba2978807f/src/UmbracoIdentity/UmbracoMembersUserManager.cs#L144

Shazwazza commented 3 years ago

If you use a custom password hasher, Umbraco CMS has no idea about it so it's never going to use it. It only knows about itself and membership providers. So it will use the password hashing algorithm specified by the membership providers only. If you want a custom password hasher, you cannot use the back office editor to create or modify members passwords.

skartknet commented 3 years ago

Thanks Shannon, I thought that the provider configured on the web,config was to inform Umbraco that it has to use that provider. And then specifying a new user manager would also configure the provider. I'm probably missing concepts here.. :(

Shazwazza commented 3 years ago

UmbracoIdentity enables aspnet Identity to be used for Umbraco members. It does this by implementing the required ASP.NET identity Manager and Store. The Store interfaces with Umbraco's underlying services like IMemberService. This library makes everything compatible with how Umbraco operates out of the box with the old MembershipProviders.

Umbraco's back office and Umbraco itself has no idea what ASP.NET Identity is, it's member manager or member store because they don't exist in the codebase (for members). So anything you configure for members for ASP.NET Identity specifically via this UmbracoIdentity package cannot affect how Umbraco's back office operates.

I thought that the provider configured on the web,config was to inform Umbraco that it has to use that provider. And then specifying a new user manager would also configure the provider.

The provider configuration is for the MembershipProvider. This library configures ASP.NET Identity to correspond to those config settings (not the other way around).

As above, it is certainly possible to configure ASP.NET Identity to be more specific than what can be configured in the membership provider (i.e. a better password hashing algorithm, different password policies) but it means that the back office is not aware of such things.

Hope that makes things clearer.

skartknet commented 3 years ago

Great explanation, thanks!