Update a Joomla 4.1.x stable or development version or a 4.2 development version prior to 4.2.0-beta1 with Two Factor Authentication enabled and used for the current super user who runs the update to a 4.2.0-beta2 or current 4.2-dev version which includes the new Multi Factor Authentication introduced with PR #37912 .
Do the same again, but before the update disable Two Factor Authentication for the current super user.
Update succeeds.
Update succeeds.
When the update package has been unpacked (i.e. progress bar comes to the end), the update ends with an SQL error about the new table for MFA missing:
You see this wherever you go in the backend, there is no way to get rid of it.
The reason is that the post-flight step with the SQL updates is not started.
The update log "administrator/logs/joomla_update.php" shows this: The last message you get is "Starting installation of new version.", but the "Finalising installation." and subsequent messages are missing.
The update succeeds when 2FA is not enabled for the super user who runs the update..
PHP version and so on don't matter.
The error happens only if the super user who runs the update is using 2FA.
I have opcache off so it's not an opache thing.
The 2FA method used by my super user (who is the only user on that site) is "Google Authenticator".
The site is on a testing subdomain which is protected with an .htaccess password.
There is nothing shown in my PHP error log file with error reporting set to "ALL" in PHP settings.
I think this is a release blocker.
Labels |
Added:
No Code Attached Yet
|
Labels |
Added:
Release Blocker
|
I think the error message is clear. The #__user_mfa
table was not created during the update. We do have the code to create the table in the administrator/components/com_admin/sql/updates/mysql/4.2.0-2022-05-15.sql
file. However you said:
The last message you get is "Starting installation of new version.", but the "Finalising installation." and subsequent messages are missing.
It looks like the update code never ran?
I think the error message is clear.
@nikosdion Sure, the message is clear.
It looks like the update code never ran?
Exactly that's the problem, and I haven't found anything in my PHP error log file which would show any error (if not supressed somehow like it seems to be in the updater or the installer library).
I must admit I haven't checked the browser console for JS errors .. will do another test and check.
But I think it is not a JS thing since it only happens if 2FA is enabled and used by the super user who runs the update. When I disable 2FA in the user management for that user before the update, then it succeeds.
P.S.: I have opcache off so it's not an opache thing.
P.P.S: The 2FA method used by my super user (who is the only user on that site) is "Google Authenticator". The site is on a testing subdomain which is protected with an .htaccess password.
I believe I know what is going on. There are a few redirections taking place at the end of the restoration. First we try to access /administrator/index.php?option=com_joomlaupdate&task=update.finalise&TOKEN=1 which upon completion redirects to /administrator/index.php?option=com_joomlaupdate&task=update.cleanup&TOKEN=1 which will bring you back to administrator/index.php?option=com_joomlaupdate&view=joomlaupdate&layout=complete
However, if you have 2FA enabled the first redirection will just be blocked as you've not gone through MFA yet. We need to explicitly allow these URLs. I'll make a PR for that. Give me some time.
However, if you have 2FA enabled the first redirection will just be blocked as you've not gone through MFA yet. We need to explicitly allow these URLs.
@nikosdion Yes, that's how it appears to be. I get a 500 for the first request in the network analysis.
I'll make a PR for that. Give me some time.
Sounds great. Thanks in advance.
Closing as having a pull request.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-06-13 12:18:18 |
Closed_By | ⇒ | richard67 |
Labels |
Removed:
Release Blocker
|
Please do test the PR, I made it very quickly without testing myself based on my understanding of what went wrong :)
Caveat: to properly test this PR you will need to wait for the build to complete and then use the prebuilt package to upgrade from Joomla 4.1 to the dev build.
Caveat: to properly test this PR you will need to wait for the build to complete and then use the prebuilt package to upgrade from Joomla 4.1 to the dev build.
I know. It's already done.
Ping @nikosdion : Do you have an idea of what could cause this issue?