DreamOn Posted April 25, 2022 Posted April 25, 2022 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 Posted April 25, 2022 Posted April 25, 2022 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 Posted April 25, 2022 Author Posted April 25, 2022 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 Posted April 25, 2022 Posted April 25, 2022 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 Posted April 25, 2022 Author Posted April 25, 2022 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 Posted April 25, 2022 Posted April 25, 2022 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 Posted April 25, 2022 Author Posted April 25, 2022 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 Posted April 25, 2022 Posted April 25, 2022 Unfortunately, the FTP/SFTP access details are incorrect.
DreamOn Posted April 25, 2022 Author Posted April 25, 2022 10 minutes ago, Jim M said: Unfortunately, the FTP/SFTP access details are incorrect. Sorry, fixed!
Jim M Posted April 25, 2022 Posted April 25, 2022 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 Posted April 25, 2022 Author Posted April 25, 2022 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.
Solution teraßyte Posted April 26, 2022 Solution Posted April 26, 2022 (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 April 26, 2022 by teraßyte Marc and DreamOn 1 1
DreamOn Posted April 26, 2022 Author Posted April 26, 2022 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 Posted April 26, 2022 Posted April 26, 2022 If computers are storing the old cookie, there isnt really anything for us to fix here. They would eventually expire of course
Recommended Posts