@juggernautsei Recreated
Except I had to go from v6 to current because I didn’t have a v7 version database and too lazy to create one. I think I found the problem but still tracking down so I don’t post some nonsense and appear the goof!
Except I had to go from v6 to current because I didn’t have a v7 version database and too lazy to create one. I think I found the problem but still tracking down so I don’t post some nonsense and appear the goof!
The particular database that I am working with started life at v5 if that helps you any by knowing that.
You are a good code hound!
Woof! Are you sure you are not getting a message in the log table?
From what I’m seeing the fail is happening on the user lookup from users table though the correct user is passed in and populated in users!
I swear i’ve been here before in the past…
Nothing in the log. I have the log set to the default E_ALL. Nothing shows. Did you get something in the log table? If so, how are you logs set?
No not the php error log but the openemr log table. i.e. SELECT * FROM `log` ORDER BY `date` DESC LIMIT 5
A lot of good that does since the log comments have been made unreadable. I can see where I attempted to log into the program. That is all.
By default, these are encode in base64 (so binary stuff won’t break it) and can be decoded here: https://www.base64decode.org/
Occasionally a user will turn on log comment encryption and then could make a quick script to decrypt these.
Ideally can simply view these within OpenEMR in the log (then the decoding/decryption is done for you).
2 Likes
@juggernautsei
Did you decode any of the log comments. If not you really need to.
The reason mine was failing is because the users table was corrupted on import using git bash.
The table keys are missing. I had this happen before when doing ONC testing mostly with CCDA. That’s why it was so familiar to me!
You really need to decode some of the log messages and report back or send to me and I do it.
I took my clinic v6.0.0 database that started life with passwords as far back as v4.0.0 and upgraded from v6.0.0 to current several time so I’m using at least two hashing methods. All okay.
I can’t figure out how PHP 8 would interfere w/o some indication by way of errors.
Besides decoding log you might take a look at user_secure table and note the usernames and fail counters.
I’m going to hold up until you decode the log messages. Those should give a clearer picture.
1 Like
Mine decoded to: “user password is expired”;
In the globals, password_expiration_days was blank. I changed it to 0. I was able to log into the upgrade.
I think some work has been done concerning passwords life after v7 so PHP 8 was just a coincidence.
Glab to here it is fixed however I would expect to see something in php error log.
I wonder if this is something we should address in patch? i.e. check for empty and set to zero or assume 0 in code.
Please show a solution in title. See ya…
I would not address this in a patch. But this thread is good for troubleshooting.
Someway the 0 issue with PHP and MySQL has to be thought about in this case.
I took the shortcut and ask chatgpt to decode the comment for me.
No, there was nothing in the PHP error log because there were no PHP fatal errors with the login. It would have been nice to have the password expired in the PHP error. Could have saved me a whole bunch of time.
1 Like
Well let’s not forget login logo placement! If the password expiration is blank then that sounds like either a bug in reset or it has been carried forward.
I wonder how did your testing password get to be blank? No this needs to be address in some way so user knows. Unsure if admin email alert covers this but that is if was set up.
This issue will cause a lot of grief for anyone affected. Not everybody knows how to update globals or even know to check the forum.
Agree to consider this a bug. Would treat the ‘’ (blank) same as 0 when using the password_expiration_days global in the auth code that checks for password expiration.