Account lock out 1hr??? [solved]

MajorPain wrote: ↑

Tue Jul 02, 2024 12:15 am

So I have a customer that forgot there password, and apparently not receiving the password reset email. Gmail issue I think as they blacklist everything to junk folders. So I manually changed the password in the admin area, and then they tried again and got locked out for 1hr. After 1hr it seems the lock is still on. I then marked their account as "Safe", which I believe avoids the login checks but still can't login and getting the locked for 1hr message.

Using 3.0.3.8

1) If the registered email starts with an uppercase letter and they attempt to login with lowercase, does that matter?
2) If "Safe" is enabled, is that supposed to avoid the 1hr lock?
3) Where in the database would I edit to remove the lick if I went that route.

For now I will increase the login attempts to see if we can get into the account.

Thanks

1. It doesn't matter - the username is case-insensitive. If you look at the "addLoginAttempt" function in "admin/model/user/user.php", you will see that the username is transformed to all lowercase before inserting the record into the database. Also, OpenCart performs an SQL query to validate the log in attempt and MySQL is case-insensitive for string comparisons, therefore, case does not matter for username.
2. Nope, it's not for avoiding the 1 hour lock. If I didn't remember wrongly, the "safe" option is for the anti-fraud feature - so customers with the "Safe" option enabled will not be blocked by the anti-fraud system.
3. Login attempts are stored in the "customer_login" table - this is shared by both customer logins and admin logins. If you take a look at the "validate" function in "admin/controller/common/login.php", you will see that it checks whether or not the username has exceeded the number of tries for logging in and if it has, it will compare between the time now and the time that the login attempt database record was last modified. You can probably remove that to prevent the lock. Alternatively, you can also clear the records from the "customer_login" table to reset the login attempts count as well.

MajorPain wrote: ↑

Tue Jul 02, 2024 8:09 am

we should have resolved the issue.