Your account has been locked. Try again in x minutes.

[DreamOn]

Hello,

Since the last update, several members have had their accounts blocked.

Here is the message displayed in login form:

Quote

Your account has been locked. Try again in x minutes.

Try this without success:

• Disable all custom apps
• Disable all custom plugins
• Clear cache
• Change these settings, then back to defaults:
  
• Clear "failed_logins" column in core_members table

Logs from a member:

When I manually unlock a member, after just one login attempt, he is locked again.

Very strange, the same timestamp is inserted 3 times in failed_logins column, when it should be different:

Can you help?

Thanks.

[Jim M]

Please note: I would not recommend editing the database directly.

Often these errors would indicate that a user has an outdated saved in their browser (or password manager) and even if they are typing one it, the browser may be overriding it. If you are able to have them try a different browser or incognito mode where this doesn't happen, it would be advised.

If it is still happening, do you have an example user I can look into here?

[DreamOn]

3 hours ago, Jim M said:

Please note: I would not recommend editing the database directly.

It was needed for testing purposes.

---

I think I may have found the source of the problem.

A few days ago, I have defined \IPS\COOKIE_PATH to ".website.com" (with leading dot), before it was not defined and cookies were saved exclusively in "subdomain.website.com" domain.

Maybe it could cause problem like this? What do you think about it?

[Jim M]

1 minute ago, DreamOn said:

I think I may have found the source of the problem.

A few days ago, I have defined \IPS\COOKIE_PATH to ".website.com" (with leading dot), before it was not defined and cookies were saved exclusively in "subdomain.website.com" domain.

Maybe it could cause problem like this? What do you think about it?

I would not define this unless you specifically need to. It can create issues but shouldn't cause an issue with logging in unless it is defined incorrectly.

[DreamOn]

4 minutes ago, Jim M said:

I would not define this unless you specifically need to. It can create issues but shouldn't cause an issue with logging in unless it is defined incorrectly.

I need it, because website.com need access to ips4_IPSSessionFront subdomain.website.com's cookie.

---

I had to deactivate the bruteforce protection because more and more members can no longer connect...

I tried to create a new member account but I do not encounter the problem..

How can you help me?

This problem is really annoying...

Thanks.

Look at this:

Some members had more than 50 login failures!
Even though they are known members.

[Jim M]

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

 

[DreamOn]

5 minutes ago, Jim M said:

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

 

Thanks for help!

I have updated the access information for you.

[Jim M]

Unfortunately, the FTP/SFTP access details are incorrect.

[DreamOn]

10 minutes ago, Jim M said:

Unfortunately, the FTP/SFTP access details are incorrect.

Sorry, fixed!

[Jim M]

Other than an abnormal storage configuration, the constant file looks correct. If you have these user's clear their cookies, are they able to login?

If not, could you please provide an example user who is having this issue?

[DreamOn]

11 minutes ago, Jim M said:

Other than an abnormal storage configuration, the constant file looks correct. If you have these user's clear their cookies, are they able to login?

If not, could you please provide an example user who is having this issue?

I will try to contact them about it.

[teraßyte]

Asking everyone to clear their cookies often turns out to be a problem. A way to bypass this step would be to change the COOKIE_PREFIX constant too. That way old cookies (with the wrong domain set) won't be checked anymore. 😉

 

(Everyone would have to login again though.)

Edited April 26, 2022 by teraßyte

[DreamOn]

10 hours ago, teraßyte said:

Asking everyone to clear their cookies often turns out to be a problem. A way to bypass this step would be to change the COOKIE_PREFIX constant too. That way old cookies (with the wrong domain set) won't be checked anymore. 😉

 

(Everyone would have to login again though.)

Good idea, problem solved with this!

But it would be great if we can used default "ips4_" cookie prefix, after switch from subdomain.website.com to .website.com.

Maybe IPS team could fix it in a next release?

Thanks!

[Marc]

If computers are storing the old cookie, there isnt really anything for us to fix here. They would eventually expire of course