Jump to content

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


DreamOn
 Share

Go to solution Solved by teraßyte,

Recommended Posts

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:
    image.png.c223d94a3ab5e2f96b215f77e6769aba.png
  • Clear "failed_logins" column in core_members table

Logs from a member:

image.png.f792707517632d8ebce3da7ed29e783f.png

image.png.f1f514f53088419834f22f3a9eb3960e.png

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:

image.png.9bf49d7993824ea9e72b6ab345210645.png

Can you help?

Thanks.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

image.png.8b7f71e7c429da7a3f5a8ab3929b4eaf.png

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:

image.thumb.png.3b8b5790a91c7a4db846049747fc494c.png

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

Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Solution
Posted (edited)

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 by teraßyte
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...