Dear Developers,
Kickstart is working until the error shown in secont attachment. This happens during cleanup-Process. So I can not restore my backups to any new server under PHP 7.4 or 7.3.29.
I bought the pro version, but there is no difference regarding to this error.
Any solution?
Best Greetings
Bernd Birkicht
#35940 Restore end with: Class FOFAesEncrypt not found error.
Posted in ‘Site restoration’
This is a public ticket
Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Environment Information
PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a
Latest post by birkicht on Wednesday, 06 October 2021 02:48 CDT
Tuesday, 05 October 2021 00:27 CDT
birkicht
Tuesday, 05 October 2021 02:04 CDT
nicholas
Akeeba Staff
Manager
Does this happen when restoring a backup of a Joomla 4 site or a backup of a Joomla 3 site? Which version of Akeeba Backup was the backup taken with?
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
Tuesday, 05 October 2021 08:44 CDT
birkicht
Dear Nocholas,
thank you for asking. It was not a problem restoring Backups from Joomla-installations until 4.0.3. The Backups taken until the preveous version 3.10.2 (with the appropriate version 8.0.11 of Akeeba Backup) are fully functional, but after migrating from Joomla 3.10.2 to 4.0.3 and taking these backups with the appropriate version of Akeeba Backup 9.0.7 or 9.0.7 Pro it was a problem (see also the custom fields, I had to provide).
The servers I tried to restore had either PHP 7.4.24 or PHP 7.3.29 (as I also provided). No matter. Same error after successful extraction, successful database-restauration, providing site-parameters and clicking NEXT will cause the described error:
/mnt/web112/d3/56/5506856/htdocs/test/libraries/src/Encrypt/AES/OpenSSL.php::L20
#0 /mnt/web112/d3/56/5506856/htdocs/test/installation/platform/models/joomlasetup.php(1020): include_once()
#1 /mnt/web112/d3/56/5506856/htdocs/test/installation/platform/models/joomlasetup.php(945): AngieModelJoomlaSetup->updateTFA()
#2 /mnt/web112/d3/56/5506856/htdocs/test/installation/platform/models/joomlasetup.php(80): AngieModelJoomlaSetup->updateEncryptedData()
#3 /mnt/web112/d3/56/5506856/htdocs/test/installation/angie/controllers/base/setup.php(23): AngieModelJoomlaSetup->applySettings()
#4 /mnt/web112/d3/56/5506856/htdocs/test/installation/framework/controller/controller.php(510): AngieControllerBaseSetup->apply()
#5 /mnt/web112/d3/56/5506856/htdocs/test/installation/framework/dispatcher/dispatcher.php(263): AController->execute()
#6 /mnt/web112/d3/56/5506856/htdocs/test/installation/framework/application/application.php(176): ADispatcher->dispatch()
#7 /mnt/web112/d3/56/5506856/htdocs/test/installation/index.php(115): AApplication->dispatch()
#8 /mnt/web112/d3/56/5506856/htdocs/test/installation/index.php(230): mainLoop()
#9 {main}
Copyright ©2006 – 2021 Akeeba Ltd. All rights reserved.
I lost really a couple of hours, not to mention the money for buying the pro version. I did not find anything online to help myself. So I need a solution. Hopefully the stack-trace will help, which I did not provide initially.
The backuped and restored Version of Joomla 4.0.3 did work correctly while doing the backup (without any errors shown).
Thanks in advance
Bernd
Tuesday, 05 October 2021 08:45 CDT
birkicht
Wednesday, 06 October 2021 01:01 CDT
nicholas
Akeeba Staff
Manager
Thank you for the details! I now understand the issue and can reproduce it — which means I could solve it. I will try to explain the nature of the issue, how I solved it and what to do.
The nature of the issue
Back in 2012 I contributed the Two Factor Authentication (TFA) feature in Joomla 3.2. There was a requirement to store its information encrypted in the database. We implemented that, using mCrypt and the site's secret as the key. Come PHP 7.0 the PHP project decided to drop mCrypt as an official extension since it had not been actively maintained from 2007 onwards. A decision was made to drop the encryption of TFA settings altogether as of Joomla 3.6.4.
When Akeeba Backup restores a backup archive it changes the site's secret. This is a security setting since the secret is also used to key the login cookies. If you have two sites with the same site secret and the same user ID you can take the login cookie from one site and use it on the other one to become logged in as that user without knowing its username, password or TFA code.
However, changing the secret means that any TFA created with Joomla 3.2 to 3.6.3 inclusive by a user who has not logged into the site since Joomla 3.6.4 was released needs to be decrypted with the old site secret and re–encrypted with the new secret. Back when Joomla 3.6 and 3.7 were fresh out of the oven it made sense so that's what we did.
Because of the way Joomla implements the decryption and the way PHP 8 treats undefined constants as fatal errors instead of PHP notices this code started breaking the restoration on PHP 8. I reported this issue to Joomla — since it affects Joomla itself — but the consensus is that probably no action will be taken other than removing the legacy TFA encryption code since it actually never really worked right in Joomla.
We tried to apply a workaround in our restoration script which does work with most Joomla 4 sites. Obviously it didn't work on your site and it's very likely that it won't work on some other sites since it's a very finicky thing trying to address a multitude of Joomla versions.
How we solved it
Your ticket made me think. Does having this code even make any sense anymore?
We have to consider that this code only makes sense if you have users who set up TFA before Joomla 3.6.4 and have not logged into the site at all ever since. So, we are talking about users who set up TFA between late 2012 and October 2016 and have not logged into the site since October 2016. October 2016 was five years ago. Someone not logging in for a year or two, maybe three if we are pushing it, is understandable. After five years we can most definitely consider this user account abandoned and not care about its TFA being broken. If they really want to log in after all those years they can contact the site administrator to reset TFA on their account.
So, my decision was to completely remove that code.
TL;DR — What you can do next
Please download and install the latest dev release from https://www.akeeba.com/download/developer-releases/akeebabackuppro-dev/rev56f77d8.html
Take a new backup with it.
Restoring it should work just fine.
Please confirm.
Thank you very much for your issue report and thank you in advance for your feedback!
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
Wednesday, 06 October 2021 02:48 CDT
birkicht
Dear Nicholas,
as you advised, I tried a backup with the provided dev-version and restored that backup now successfuly and without any problems on the server, which caused the error before. It seems to be working now.
Thanks a lot for your excellent and fast support and for the very clear explanation, which helped me to understand the reasons for the problem. Indeed, that was a complex "hack", which caused obviously more problems than benefit. I can understand the decision to get rid of it. And it works now fine.
I will report any other problem of course, if there may one occurs in future.
Best wishes and greetings
Bernd