Sudden Admin login issue

[DrByte]

Your prior post said that you resolved it by deleting the admin user and creating a new one? Do the symptoms continue to persist now? Does it affect all the admins equally?
The person whose post you added yours onto said that their symptoms affected the storefront end as well. Did that happen to you?

[weif]

Your prior post said that you resolved it by deleting the admin user and creating a new one? Do the symptoms continue to persist now? Does it affect all the admins equally?

No, as I mentioned, it only affected one admin account.

The deletion of the account and creation of a new account *seems* to have corrected the issue. However, changing the password did not, nor did changing the username. Logging in to this one account (or attempting to, at least) resulted in the login page reloading. This was tested on three different computers, and with Chrome, Firefox, and Internet Explorer on Windows 7 and on FreeBSD (well, obviously IE was not tested on FreeBSD). On two of the computers used for testing, other admin accounts could log in.

The person whose post you added yours onto said that their symptoms affected the storefront end as well. Did that happen to you?

There are only two customer accounts, and both of these are able to log in.

[lhungil]

I know I've run into issues when an Admin User uses the "forgot my password" form and either does not receive the email. In this case, until the reset_token expires, changing the password manually using another admin account appears to have little effect. After going into phpmyadmin or similar and removing the "reset_token" from the affected user account, the password reset from the admin interface works.

I suppose the easiest way to handle this case might be to correct the user's email address and then they can probably just call the "forgot my password" form again - but I've just gone in and removed the reset_token the handful of times I have seen this case occur.

I've also seen similar symptoms when an Admin User forgets their password and triggers an account lockout... Until the lockout period expires, even if the password is manually reset by another admin account, the affected Admin User account cannot login.

[DrByte]

I know I've run into issues when an Admin User uses the "forgot my password" form and either does not receive the email. In this case, until the reset_token expires, changing the password manually using another admin account appears to have little effect. After going into phpmyadmin or similar and removing the "reset_token" from the affected user account, the password reset from the admin interface works.

I suppose the easiest way to handle this case might be to correct the user's email address and then they can probably just call the "forgot my password" form again - but I've just gone in and removed the reset_token the handful of times I have seen this case occur.

I've also seen similar symptoms when an Admin User forgets their password and triggers an account lockout... Until the lockout period expires, even if the password is manually reset by another admin account, the affected Admin User account cannot login.

Perhaps it might be good to file a bug report explaining these symptoms. Also, you used the word "either" in your first sentence but didn't finish the thought which it implied. Further, the whole reason for the reset-token is specifically so that if the email is not received that the original password will still indeed work, unlike prior versions where the password was immediately changed to whatever was in the email and then the account became totally useless without the email. The system doesn't currently consider unlocking things by another administrator; that could be an oversight which needs addressing.

[lhungil]

... you used the word "either" in your first sentence but didn't finish the thought ...

Forgot to remove the word "either" when previewing / editing before posting

A) did not receive the email B) the wrong email was listed in Zen Cart for the account C) email went to spam / junk D) Email subsystem turned off E) Email misconfiguration

... the whole reason for the reset-token is specifically so that if the email is not received that the original password will still indeed work, unlike prior versions where the password was immediately changed to whatever was in the email and then the account became totally useless without the email. The system doesn't currently consider unlocking things by another administrator; that could be an oversight which needs addressing.

I do like the new reset_token in 1.5 - and I believe it is also configured out of box to force the user to change the password if they use the reset_token (I'd have to take a deeper look at the code, but this is what I remember the last time i used the password_forgotten form).

I consider the enforced password change a nice security feature. Far too many people think unencrypted email is a safe method for transmitting passwords days!

When I get some time, I plan to look at the code in more detail and post something in "Code Suggestions".

[DrByte]

and I believe it is also configured out of box to force the user to change the password if they use the reset_token (I'd have to take a deeper look at the code, but this is what I remember the last time i used the password_forgotten form).

correct. If they use the token, then they must subsequently choose an actual new password.

I consider the enforced password change a nice security feature. Far too many people think unencrypted email is a safe method for transmitting passwords days!

Agreed.
And the token expires after a couple days, so cannot be misused months down the road by someone taking over a former employee's email, etc.