- Issue created by @xiwar
- 🇨🇴Colombia sebasgd
I'm having the same issue after removing ga_login module and updating tfa to the latest version.
We're seeing the same issue after the latest security update (1.1).
- 🇬🇧United Kingdom the_g_bomb
Can't say for sure, but looking at the code, I suspect this:
public function getLoginDefinitions(bool $active_only = TRUE) { $plugins = $this->getClassDefinitions('\Drupal\tfa\Plugin\TfaLoginInterface'); if ($active_only) { $login_plugins = $this->tfaSettings->get('login_plugins'); $plugins = array_filter($plugins, function (array $plugin) use ($login_plugins) { return ($login_plugins[$plugin['id']] ?? NULL) === $plugin['id']; }); }
I can see that it is called here at least once by using:
$login_plugins = $this->pluginManager->getLoginDefinitions(FALSE);
but if it called with active_ony set to false nothing is returned as there is no else statement.This was introduced in #3319595: Login plugins are always applied even when not enabled →
- 🇺🇸United States cmlara
I haven't looked at this in depth, however I'm wondering are any of the deployments using any read-only config modules, or have any form of config overrides in place?
Quick glancing to me that is the only scenario that to me would meet the description above of config being successfully saved, but not retrieved with the new values.
We're using config ignore on our website, however, the TFA module is not part of the ignored configurations.
We're also using config redonly but TFA is whitelisted for changes.
We also activate TFA (using "tfa.settings">"enabled") on an environment basis using a settings.inc file. It's the only amend done to the TFA module via the settings files.Hope this helps.
Thanks!
- 🇬🇧United Kingdom Alina Basarabeanu
We came across this issue and found out the following settings on settings.php always override the configuration split:
$config['tfa.settings']['enabled'] = FALSE;
Make sure that the settings are stored in one place. - 🇺🇸United States cmlara
The settings.php $config seems like a good one to check, a FALSE in there would indeed usually take priority, and worse yet Configuration Forms do not show the overridden value so it can appear as if TFA is enabled when it is not ref: 🐛 Display status message on configuration forms when there are overridden values Fixed .
@carolea If it isn't the settings.php I would be looking at the other config modifying modules as I'm not seeing this in any of my lab installs.
Thanks, it was my first check before replying here and the value is set to TRUE in the settings.php file.
TFA seems to be activated, it's just that users with TFA don't get prompted upon login and when they go in their TFA tab, they see "Currently there are no enabled plugins."
The config still has the GA TOTP activated and as default method, it just doesn't show up for the users (whether they try to set up TFA now or if they already had TFA enabled) and they don't get requested to activate TFA when they log in.
It's working just fine with version 1.0.0-alpha8.
Was there a big change in this security update?- 🇺🇸United States cmlara
It's working just fine with version 1.0.0-alpha8. Was there a big change in this security update?
In the security update, no, in the code since 1.0.0-alpha8 yes.
1.0.0-alpha10 in particular made major changes to the plugins. the GA plugins were removed and merged into TFA under new names.
#3208224-12: Merge ga_login module → may have some relevant information regarding configuration during/after the upgrade (written regarding config split, but equally relevant here)If you haven't executed the post upgrade hooks that might explain the issues you are seeing. Note after running the hooks revering back to Alpha8 is not possible (without rolling back the database.)
Hi,
Sorry for late reply.
We always run the updb hooks so I don't think the issue comes from there.
I'll have a look at the link you sent to see if we missed something there.
Thanks!