Cannot login to OpenEMR on any account

noscrodamus wrote on Friday, April 08, 2016:

I’ve recently exported a database from the problem server to a working openemr server. I cannot log in to openemr under any users, I know the passwords are correct. When opening the login screen the error message "invalid username and password’ automatically come up in the login frame even before I have entered any username/password combinations. I have even tried changing the passwords in the ‘users’ and ‘user_secure’ tables in the DB. No idea what is going on.

fsgl wrote on Friday, April 08, 2016:

Did you use the MySQL root password of the receiving database (not the one from which you created the mysqldump), to import into the functional server?

noscrodamus wrote on Friday, April 08, 2016:

I may have.
The mysql root password for the recieving server is the same as the openemr’s admin’s user password on the non-functioning server. Atleast I think it may have been.
Why would this cause an issue?

noscrodamus wrote on Friday, April 08, 2016:

I may have.
The mysql root password for the recieving server is the same as the openemr’s admin’s user password on the non-functioning server. Atleast I think it may have been.
Why would this cause an issue?

yehster wrote on Friday, April 08, 2016:

What may be happening is that the MySQL account openemr is using to try to access the database does not exist. (A dump and a restore does not recreate MySQL accounts, just the tables).

To debug, suggest that you edit your sqlconf.php file in sites/default

trying root and the mysql root password for the $login and $password fields.

If this test restores access, it’s generally not a good idea to use the root account for openemr access, so you’ll need to create a new mysql user and password with appropriate permissions specifically for openemr to use. However, since you’ve modified data in the users_secure table, you might have invalidated the existing openemr users, even if this is the cause of your problem.

noscrodamus wrote on Friday, April 08, 2016:

This would only apply to the machine the sqldump is executing queries to, no? Im having trouble with the machine that created the sqldump. Also, I was able to log onto mysql via phpmyadmin and via console on both machines using the credentials in sqlconf.php. It is the openemr user accounts i am having difficulty accessing.

I have also attempted to change the passwords for these user accounts using both plain text and hashed passwords provided by the login.php file and stuff ive found on your forums. none working

yehster wrote on Friday, April 08, 2016:

Since phpmyadmin login is possible my hypothesis about it being a mysql user issue seems much less likely however, there might still be permissions problems with the database that testing with the root user might identify.

Are you able to login with openemr users on either server? Did the “non-working” server ever work?

noscrodamus wrote on Friday, April 08, 2016:

i was able to log into the non-working server when i first installed it, since then i havent had a reason to log in as i was changing the look for the login screen ( html stuff in login_frames.php and login.php)

I am able to log into the new server without any issues. Im assuming the problem occured at the point of creating the sqldump.

I think this may be vital:

know the passwords are correct. When opening the login screen the error message "invalid username and password’ automatically come up in the login frame even before I have entered any username/password combinations.

yehster wrote on Friday, April 08, 2016:

It seems more likely that the changes that you made to login_frames.php and login.php are the culprit on the non-working server.

Have you tried restoring those to the default versions and seeing what happens?

noscrodamus wrote on Friday, April 08, 2016:

yes. i created backups before i altered the files. and they are the same as the ones on the working server

fsgl wrote on Friday, April 08, 2016:

When OpenEMR is installed, the phpMyAdmin login password is not set. Being able to access the database via phpMyAdmin may not rule out a MySQL credential problem.

Even if that password is set & a user can get into phpMyAdmin, writing to the tables may not be possible.

If OE had been installed with a root MySQL password, it is necessary to supply it when using the restore script.

Given the fact that you tried the fix in the users & user_secure tables & failed, it may not be a login problem when launching the application.

Try the following:

  1. reset the root MySQL password on the defective device & write that password down.
  2. create a mysqldump on functioning device.
  3. restore 2 to 1 using the reset password that was written down in 1.

Users often don’t write down passwords & generally assume everything remains the same across devices, only to find out that is not the case.

If the above fails, try to install a new copy of OE to the faulty device & restore from functional machine.

Another thought is to create a system image before any change to the codes. Not very elegant, but if troubleshooting yields nothing, at least it’s easy to get back to a point when life was calm.

yehster wrote on Friday, April 08, 2016:

Does the non-working login screen present a list of languages? If so, then that means it is connecting to the database appropriately.