editor - Login failed, changing password via API did not work

[700ml]

(Update: system info:

ProcessWire Version: 3.0.210
Hosting Information: shared hosting via cPanel @ Namecheap
PHP Version: 7.4
Mod_Security: disabled

)

Hello dear community,

I have been working on the website one week ago, changing the char_sets in the database via PhpMyAdmin from utf8_bin to utf8mb4_general_ci. In order to enable emoji support. And I turned off the ModSecurity in cPanel on my shared hosting, as asset uploads were not working properly.

Everything worked fine with logging into "admin" or "editor" user. Now, I've returned to work on the website 6 days later, and I am stuck at the "Login failed" message. When I look in `/site/assets/logs/session.txt`, there is a message that says:

`2023-06-12 22:03:43    guest   https://www.website.com/admin/login/  Error: Failed login for 'admin' - Invalid password`.

I am completely unsure regarding what to do, and I am in urgent need of any help.

I have tried to reset the password as per this tutorial:

With several variations of the fix. Nothing has worked so far.

Any advice and practical pointers or troubleshoot steps would be more than welcome. I made a backup of the database before updating the charsets and collations. This is my first important client project and I am terrified of it not working. Thank you again for any help or pointers.

[bernhard]

$users->get("name=admin")->setAndSave('pass', 'yoursupersecretpassword');

If you put that in ready.php and visit your site once (load any page), then you still can not login?

Have you also tried logging in from an incognito window? Maybe some cookies are messing things up?

[700ml]

(update: sadly not working; see below)

Hey! Thank you so much for your reply. The steps you proposed worked, and I was able to login. Huge relief, thank you once again!! ?

I have no idea what caused the error all of a sudden. I imagine changing the character encoding of all the utf8_bin fields was one step too far... I've dialed back the changes in PhpMyAdmin to their defaults for all `pages` and related tables, while keeping it at utf8mb4_unicode_ci for the template tables and text-input fields...

And for some reason, pasting the password reset code into the homepage template file, under the php opening code, did not work...

Thank you once again.

[700ml]

Update: Added system info in my first topic post. I have logged out, changed the line of code in ready.php to update the password for Editor (by adapting the same code from your answer) and was able to log in into Editor... Now, I am trying to login into Admin, after noting and keeping the new password,to receiving the same error:

• admin - Login failed

I have tried both the new and the old password, to no success. I wonder what could be causing this...

 

The suggested method only seems to work, when the line changing the user password, is enabled in `/site/ready.php`. As soon as I comment out the line, log out, and try to log in again,the same error persists. My only suspect could be some encoding fault in the database? but perhaps I am wrong.

[bernhard]

11 hours ago, 700ml said:

The suggested method only seems to work, when the line changing the user password, is enabled in `/site/ready.php`. As soon as I comment out the line, log out, and try to log in again,the same error persists. My only suspect could be some encoding fault in the database? but perhaps I am wrong.

This sounds weird. I don't know enough about character encoding of databases if that could also be the reason for such a behaviour though. What could result in something like this is if a hardcoded password is set somewhere before ready.php - This would explain why it works as long as the line is present in ready.php but as soon as you remove it it does not work any more.

Can you log in as admin, then create a new superuser in the backend and then check if the login for that user works persistently?

[Gideon So]

Hi @700ml

Have you added $config->dbCharset = 'utf8mb4'; to the config.php??

Gideon

[700ml]

On 6/13/2023 at 10:51 AM, bernhard said:

This sounds weird. I don't know enough about character encoding of databases if that could also be the reason for such a behaviour though. What could result in something like this is if a hardcoded password is set somewhere before ready.php - This would explain why it works as long as the line is present in ready.php but as soon as you remove it it does not work any more.

Can you log in as admin, then create a new superuser in the backend and then check if the login for that user works persistently?

Thank you for your reply. I have done so – created a new superuser "admintest", set a password. Tried to login from a new tab, then new incognito window, no luck: login failed. I couldn't foresee where such a hardcoded password could be set/found... At this point, I am thankful I am still able to login using the ready.php hack, but it does not feel like a good longterm solution ?...

On 6/13/2023 at 11:00 AM, Gideon So said:

Hi @700ml

Have you added $config->dbCharset = 'utf8mb4'; to the config.php??

Gideon

The line was in my `site/config.php` file, thank you for the tip... The problem has happened nonetheless ?

[bernhard]

Maybe you need to set your field_pass table to ascii_general_ci ? At least this is what it shows for me. Maybe that's messing things up?

[wbmnfktr]

Do you have a backup of your config.php file prior to any changes or maybe something in Git?
Somehow this sounds like a messed up $config->userAuthSalt or $config->tableSalt.

 

[netcarver]

I think @bernhard might be on the right track here. If you've changed the charset for the password table from the default, that would likely break things.

[700ml]

On 6/14/2023 at 6:26 PM, bernhard said:

Maybe you need to set your field_pass table to ascii_general_ci ? At least this is what it shows for me. Maybe that's messing things up?

I've changed the charset to "ascii" and collation of field_pass to "ascii_general_ci", and created a new user "admintest". the " login - failed" still persists...

On 6/14/2023 at 6:38 PM, wbmnfktr said:

Do you have a backup of your config.php file prior to any changes or maybe something in Git?
Somehow this sounds like a messed up $config->userAuthSalt or $config->tableSalt.

I'm afraid I don't have any meaningful backup ? Is there a way to repair this?

At this point, I am unsure what went wrong. The problems definitely appeared after modifying the table character encodings and collation. I wrote a SQL query which modified all the utf8_bin fields into " CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci". I then manually reverted the non- "text" or "mediumtext" or "longtext" type fields back to the previous default "utf8_bin" using the PhpMyAdmin graphical UI.

I've also noticed that the "field_pass" in this database shows "type": char(1) , for the data and salt rows. When inspecting other databases for other ProcessWire projects, it shows char(40) and char(32), respectively.

[bernhard]

55 minutes ago, 700ml said:

I've also noticed that the "field_pass" in this database shows "type": char(1) , for the data and salt rows. When inspecting other databases for other ProcessWire projects, it shows char(40) and char(32), respectively.

I think that would explain the behaviour! Have you tried changing it to those values?

Column	Type	Comment
pages_id	int(10) unsigned
data	char(40)
salt	char(32)