Thread: Reset password not working

When a user requests a password to be reset they recieve the email. When entering the new password they get a message saying

Your password has expired, please change it now.
You are required to change your password

If they enter the old password and a new one they then get

You are required to change your password

They cant get past this and cant reset a password.

The PwdChangeRequired field is set to 1 for this user and doesnt change. If I manually change it to 0 then this solves the problem but of course isnt the solution.

Any idea what could be causing this?

Lets try the easiest stuff first.

Are you entering the newly generated password as the "old password"? Many users get confused and try to enter their password from before it was re-generated.


Ryan

Yes, the new password from the email. I have tried it with 4 different users and all the same.

We are actually experiencing this same issue now. I think it has something to do with the password strength/length validation failing, but not reporting back to the front end. But also doing something to the customer record that changes that original temp password.

So you get stuck in this loop, only way out is to request a new password again.

Please let us know if there is a patch or someway to fix this.

Thank you,

Jason G.

I am having this same issue
just upgraded to v9

I recompiled my solution and re uploaded the bin folder and it worked, at least for now anyways

I am having this same issue as well.

We have a client who is experiencing the same issue. What's strange is it does not happen in our dev and test environments and we have the code synched between all three.

If your database is on a separate server make sure the server time is the same

Same server here

Is it the admin user that can not sign in? if so try login in at /your-admin-dir/signin.aspx

This is a normal customer. This seems to be an issue with passwords generated because I'll get a password sometimes with special characters and won't be able to login at all. I'll have to request a new password and then the customer will have to reset their password where they get in the loop. I have tried supports patch but no luck on my install. I'm still researching though.

Still no luck here, Vortx sent a patch, but the problem still persists. Our client is getting very frustrated.

We've updated the code to not require a password change when they request a new password as a temporary fix.

The code we changed was in /App_Code/ASPDNSFMembershipProvider.*

The ResetPassword function

Changed the line to:

c.UpdateCustomer(Nothing, Nothing, p.SaltedPassword, p.Salt, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, lockuntil, Nothing, -1, Nothing,0, Nothing) 'RegisterDate - PwdChangeRequired - Active - BadLogin - AdminCanViewCC - LockedUntil - IsRegistered - StoreCCInDB - VATRegistrationID - VATSetting - CurrencySetting - Over13Checked - Deleted - FinalizationData - ExtensionData - CODNet30Allowed - CODCompanyCheckAllowed - GiftRegistryHideShippingAddresses - GiftRegistryNickName - GiftRegistryAllowSearchByOthers - GiftRegistryIsAnonymous - GiftRegistryGUID - ShippingAddressID - BillingAddressID - RecurringShippingMethod - RecurringShippingMethodID - MicroPayBalance - LocaleSetting - OrderOptions - RTShipResponse - RTShipRequest - SubscriptionExpiresOn - OrderNotes - LastIPAddress - BillingEqualsShipping - IsAdmin - OkToEmail - CouponCode - Referrer - AffiliateID - Phone - SkinID - Notes - LastName - FirstName - Gender - DateOfBirth - SaltKey - SaltedAndHashedPassword - EMail - CustomerLevelID

I have noticed that on the admin site I have no problems resetting my password via email and logging in and being forced to change my password. This works fine on here. When I compare the logins, I see that there are some differences between the admin signin and the customer signin.


A few differences I see are that in the non-admin site, It uses:

Code:

MembershipUser user = System.Web.Security.Membership.GetUser(EMail);
string newPassword = user.ResetPassword();

And the admin site uses:

Code:

Customer c = new Customer(EMail);
Password p = new Password();

I also see a diffference in the changepwd_onclick on the admin site and the btnChgPwd_Click on the customer login. Just wondering if anyone else has looked into these differences?

Anyone find a resolution? I'm still getting the loop even after installing new Signin.ascx.cs and SkinBase.cs from support.

Everything behaves as expected right after the site has been restarted. The second use of change password begins an endless loop of "you are required to change your password."

When I step through the code (2nd time thru) in ASPDNSFMembershipProvider.cs, I can see that args.Cancel is false and args.Password holds the correct value. That's good. However, when it calls controls/Signin.ascx.cs at Membership_ValidatingPassword, PasswordField retains the incorrect, old value; confirmpwd retains the incorrect, old value; but e.Password contains the correct, new value. Because e.Password is correct but confirmpwd is incorrect, it gets trapped in the IF statement below that sets e.Cancel to true. Once set to true, the loop begins.

Code:

void Membership_ValidatingPassword(object sender, ValidatePasswordEventArgs e)
        {
            String PasswordField = tbOldPassword.Text;
            String confirmpwd = tbNewPassword2.Text;
            if (PasswordField == e.Password)
            {
                lblPwdChgErr.Text = AppLogic.GetString("signin.aspx.30", m_SkinID, ThisCustomer.LocaleSetting);
                lblPwdChgErr.Visible = true;
                e.Cancel = true;
            }
            if (e.Password != confirmpwd)
            {
                lblPwdChgErr.Text = AppLogic.GetString("signin.aspx.32", ThisCustomer.SkinID, ThisCustomer.LocaleSetting);
                lblPwdChgErr.Visible = true;
                e.Cancel = true;
            }

Should these password fields be retaining old values? Membership_ValidatingPassword iterates through all the old passwords used in the current session and finally arrives at the correct password values; but it is too late, since there is no way to change e.Cancel back to false.

It only goes bad on the second (and subsequent) use of change password. Does anyone have ideas about what I could check to ensure these old values get cleared out? (I have verified that Signin.ascx & Signin.ascx.cs, Skinbase.cs, ASPDNSFMembershipProvider.cs, match the 9.013 source.)

I haven't been able to track this down as far as you have but it definitely sounds like a good start. I too have gotten the copy of skinbase.cs and signin.ascx.cs from support. That "fix" doesn't seem to solve the issue and if I try to ask about it, I'm told that customized versions are not supported.

What you are saying makes a load of sense though and I'm going to take a look this afternoon.

I was having this same issue after making a type when confirming the new password. The second attempt, while correct, would still fail because Membership_ValidatingPassword would still run both password change attempts and cause c.Cancel == true as described above. I solved this by adding the following line c.Cancel = false; at the begining of the method.

Code:

void Membership_ValidatingPassword(object sender, ValidatePasswordEventArgs e)
        {
            String PasswordField = tbOldPassword.Text;
            String confirmpwd = tbNewPassword2.Text;

            e.Cancel = false; // reset Cancel
            if (PasswordField == e.Password)
            {
                lblPwdChgErr.Text = AppLogic.GetString("signin.aspx.30", m_SkinID, ThisCustomer.LocaleSetting);
                lblPwdChgErr.Visible = true;
                e.Cancel = true;
            }

This code is in Signin.ascx.cs and MobileSignin.ascx.cs.

The initial problem that got me started down this path was that I had added a couple arguments to UpdateCustomer, but forgot to change the stored procedure. The stored procedure would fail, but everything seems ok on the front end, no errors. I think this failure would get me in the never ending loop.

Adding e.Cancel = false; // reset Cancel after the strings seems to be working perfectly. My only problem I see now is that it doesn't actually log the user in after resetting their password. Any suggestions on this?

Also, is anyone noticing an issue when the password generated by aspdnsf contains special characters?

This is working for me too. Thanks, j7.

Chris, my results are the same. My users get a message saying the password has been changed, but the user must actually take the extra step of signing in with the newly changed password. Anyone know if this is the expected storefront behavior?

I haven't noticed any problems with passwords generated by aspdnsf when they have special characters.

(Side note for anyone having issues with sigining in... Although the release notes for 9.013 mentioned use of standard .NET membership, I didn't know enough to realize that there was a new section in the web config with properties that control password length and special characters, etc. - I got too caught up with converting the pages. If you haven't yet checked this out, learn from my humbling experience.)

We found and fixed the problem in the Service Pack, released an hour ago. Release notes are here

This service pack is free to all ML9 users - it can only be applied to 9.0.1.3 - all earlier versions will need to be upgraded (also available free).

There's still a large pile of stuff we need to do, but its significantly more robust and MultiStore is beginning to play very nicely. An admin Service Pack will follow very shortly.

Jo

Applying the signin.ascx.cs fixed the issue for me at least. It was a direct copy without anything needed to be modded. I used winmerge first to see the differences (there are a lot). I'm not having the problems with special characters and the user is actually logged in after changing their password.

My only question is, why was I told by support that the file that was sent to me as a patch was the fix to this issue when it really wasn't and when I still had the issue, I was told that I couldn't be supported anymore because of customizations?