Specifically Upgrading from 7.0.0 (1) to v7.0.2: log in fails because global setting

Day-to-Day Users
#1

Here is the error message:
PHP 8.1.2-1
ubuntu 2.14
Apache 2.4.52 (Ubuntu)

PHP Fatal error:  Uncaught Twig\\Error\\LoaderError: Unable to find template "right" (looked into: /var/www/html/openemr/templates). in /var/www/html/openemr/vendor/twig/twig/src/Loader/FilesystemLoader.php:227
Stack trace:
#0 /var/www/html/openemr/vendor/twig/twig/src/Loader/FilesystemLoader.php(131): Twig\\Loader\\FilesystemLoader->findTemplate()
#1 /var/www/html/openemr/vendor/twig/twig/src/Environment.php(264): Twig\\Loader\\FilesystemLoader->getCacheKey()
#2 /var/www/html/openemr/vendor/twig/twig/src/Environment.php(312): Twig\\Environment->getTemplateClass()
#3 /var/www/html/openemr/vendor/twig/twig/src/Environment.php(280): Twig\\Environment->load()
#4 /var/www/html/openemr/interface/login/login.php(265): Twig\\Environment->render()
#5 {main}
  thrown in /var/www/html/openemr/vendor/twig/twig/src/Loader/FilesystemLoader.php on line 227

What happened:
Copied the entire documents folder from the old server to the new server 2.5GB.
Created a new database using the 7.0.2 code.
Truncated the database dropping all the tables.
Imported the 7.0.0 (1) database into the database created by the install program.
Ran the SQL upgrade script.
Tried to log in with previously used username and password.

Unable to login, checked the log file and the error message above is in the errors log.

Note by administrator 11/30/23: The error message above has a solution by @Penguin8R here: Specifically Upgrading from 7.0.0 (1) to v7.0.2: log in fails because global setting - #4 by Penguin8R
@juggernautsei concern is further described here: Specifically Upgrading from 7.0.0 (1) to v7.0.2: log in fails because global setting - #8 by juggernautsei

Fixed in v7.0.2 patch 1

#2

Truncating doesn’t drop the tables so that will interfere with the upgrade.

Maybe I misunderstood and you did drop the tables @juggernautsei , can see a previous post that looks similar.

#3

This is not connected with the previous post. I have run into this before. I am posting to see if anyone else has seen this. I am still doing an upgrade on a different server. @stephenwaite

1 Like
#4

We ran into this before, took me a bit to find my notes on the issue, it came down to incompatibility in one of the globals values from the previous version versus how the latest version of the software tried to interpret and use the globals settings. Check the value of the global variable called “login_page_layout” in your problem system. This was the fix:

UPDATE globals SET gl_value = ‘login/layouts/vertical_band.html.twig’ WHERE globals.gl_name = ‘login_page_layout’ AND globals.gl_index = 0;

Note from administrator 12/02/23: This is fixed by running the v7.0.0 to v7.0.1 upgrade option!

#5

@Penguin8R thanks for that piece of information. I will try that as soon as I can figure out this.

I backed up and tried to created a clean database with the keys from the v7.0.0 which I will be upgrading from. My thinking was that if I could create a clean database using the existing keys. It would help me figure out the issue that @Penguin8R solved.

Well, it did not. Now I have an issue I saw before but side stepped and now I am back to again.
When I try to create a new database using the previous v7.0.0 keys. The system throws this error.

OpenEMR Error : Decryption failed authentication., referer: http://myipaddresshere/openemr/setup.php?site=default
 OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting., referer: http://myipaddresshere/openemr/setup.php?site=default

@#$%^&*

That seems it was not a good thing to do. I am going to try to upgrade the database again and then run the command that @Penguin8R posted. I will get back to you all with an update.

#6

I had to change the title of this thread to match the situation.
After much testing today. The root issue is the upgrading from php7.4 to PHP8.1. The keys no longer work. I made a copy of the server that I want to do the upgrade from v7.0.0 (1) to v7.0.2.

The installation has Ubuntu 20.04, Apache 2.4.41, and PHP7.4. I am able to log into the application 7.0.0 (1). When I upgraded PHP to version 8.1 and everything else stayed the same. I was unable to log in with the same username and password. Rolled the system back to 7.4 and was able to log in again.

Did an upgrade from 7.0.1 (1) to 7.0.2 and it worked.
So, we are going to try doing the upgrade to 7.0.1 from 7.0.0.

#7

I don’t follow! What keys no longer work and how did you come to that conclusion?
Can’t log in? Get a white screen?
I’m pretty sure the file system encryption keys are not relevant to decoding user passwords. So what leads you to believe something is wrong with encryption?

#8

I thought I was being as clear as possible.

When I upgrade the PHP version. I am no longer able to log in. It displays, invalid username or password.

Flip it back to the previous version of PHP and I can log in with the same username and password.

The only thing that changes is the system is the PHP version.

That is why I hypothesized that it has to be the keys. We are not passing clear text from the database to my knowledge. The password stored in the database needs to be decrypted and compared with the password entered in the form (this is my theory).

What else could be going wrong? Any suggestions are welcomed.

#9

Sounds like you’re a bit frustrated Sherwin. Your title suggests the solution are the keys whereas I’m not so sure.
I tested upgrade from 7.0.1 and new install with no issues before release. However I will do some more testing and see if I can see any issues you are experiencing by upgrade from 7.0.0 to current.

Hand in there buddy!

1 Like
#10

hi @juggernautsei ,
User credential password are stored via hashing (do not use the keys). Recommend looking at the OpenEMR log after a failed login to see the message and going from there.

#11

Did anyone fix this in codebase? It seems even if put in a patch we’d need to post a warning in upgrade instructions to apply patch if previous version used right logo.

#12

@juggernautsei Sherwin, I’m still trying to recreate. Try Brady’s suggestion. I’d expect a console or php error if a php version issue so the log will most likely provide us more guidance.

#13

@brady.miller There is nothing in the log this time. That is the frustrating part.
I have done other upgrades successfully. This one is giving me trouble.
@sjpadgett here is the console log.

image
image1590×191 21 KB

image
image1576×764 63 KB

What I am going to attempt today is to push past logging into 7.0.0 and replace the code with 7.0.2 and see if I get the same error. There could be an incompatibility in 7.0.0 with PHP 8.1 that there is no need to fix.

Thanks!

#14

Generally when upgrading PHP version especially v7 to v8 several changes are required to php.ini so could you have missed an extension or setting existing in v7 php? I know hashing change some in v8 but nothing I see to cause us difficulties.
I suspect something is going wrong with how you move the database. Is this on a server you have debug access to?

#15

This is a clue and may have to do with the google log on Ken put in. At this point I’m a confused old man as where you are with your many test to try to isolate.
I find it important to know if we have an issue upgrading from 7.0.0 to current as that can be a process for many users going forward so Sherwin, I’m trying to hang in there with you. That is if the forum god’s will quit complaining I’m posting too much!:slight_smile:

Edit: @juggernautsei I finally recreated

[30-Nov-2023 07:30:32 America/New_York] OpenEMR Error : Decryption failed authentication.
[30-Nov-2023 07:30:32 America/New_York] OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting.

Now I need to figure out how to explain.:slight_smile: I’ll get back to ya…

#16

@sjpadgett I am not moving the data.

  1. On AWS, I can make a copy of the entire server. So, no need to move data.

  2. I install PHP 8.1 and all of its dependencies

    sudo apt install php8.1-common php8.1-mysql php8.1-xml php8.1-xmlrpc php8.1-curl php8.1-gd php8.1-imagick php8.1-cli php8.1-dev php8.1-imap php8.1-mbstring php8.1-opcache php8.1-soap php8.1-zip php8.1-redis php8.1-intl -y

  3. I disable PHP 7.4

    sudo a2dismod php7.4

  4. I enable PHP 8.1

     sudo a2enmod php8.1

This is where I am on the copied server which is exactly the same as the production server.
So, I am going to bring in 7.0.2 this morning and see what happens.

Yes, I updated the php.ini settings in 8.1.

@sjpadgett I think we have the same mission to put as much technical information out as possible. That is the reason I post my exploits. To help someone in the future. If we set off the forum god’s so be it. I have been censored before. We are passionate about what we do and it shows.

#17

Okay but simply installing the extensions doesn’t necessarily mean the php.ini jives with what’s available to it. No matter I’m not very sure that is the issue though sequel engine version could perhaps.
I’ll continue to try to recreate the error/issue by following your testing path. You know why, I assume, you got the first errors dealing with decrypt.

#18

I disabled the Google login and was still unable to log in after switching from v7.0.0 code to v7.0.2 code according to the instructions given. Here is the console log.

image
image1593×219 17.9 KB

image
image1174×245 20.8 KB

image
image1187×720 43.5 KB

image
image1179×723 39.3 KB

#19

I no longer get the decrypt error.

The upgrade does the same thing no matter if I create a new server and move into it or if I do this upgrade that I did this last time so that I don’t have to move data. The end result is the same, the login breaks.

It has to be something in the database and the hashing of the password.

I have done a clean install of v7.0.2 and logged in. Then import the v7.0.0 database, upgrade, and the login breaks.
So, the hash is not being read from the v7.0.0 database. I will head down that rabbit hole tomorrow.
Time to go make the donuts.

#20

Nuts, now I want a donut. You could have kept that to yourself!

1 Like