@nelo_drup thank you for the support of the module, I have updated the project by setting you as maintainer.
@pfrilling You specified it, my bad.
I applied the patch.
The user/logout route now returns a 403.
This is the logical behavior, but is it the expected behavior?
Shouldn't we have the confirmation form?
Just got again the error today and a bot crash my drupal website.
patch #10 works for me.
User gets redirect to the separate password when resetting its password.
Same problem here.
If we use the override option for the recovery password mail, it won't work since we can't get the one time url login token.
@bhanu951, sorry for the delay.
What's the command to import recovery code ?
migrate:import tfa_migration_recovery_code --update
?
Tried with tfa_migration_totp_seed && tfa_migration_user_settings. Got same results.
I copied the code from your merge request.
I am sorry, please find the extract of the table.
Hi @bhanu951, of course
Thank you, patch #7 fix the warning.
Same here
Re-open.
After checking the TFA User Settings migration process, it appears that the 'tfa_basic_recovery_code' plugin is migrated.
But the recovery codes are not.
This results in the user's TFA configuration contains the tfa_recovery_code plugin.
As a result, when the user logs in, he can use a recovery code plugin but since theses codes are not migrated the form cannot be displayed (the page reloads).
The recovery codes are in the 'tfa_recovery_code' table.
I don't know if we can migrate them. If not, the following code should be remove :
// Check to see if the user has recovery codes enabled. If so, add it
// to the plugins array.
if (isset($decoded_data->plugins[1]) && ($decoded_data->plugins[1] == 'tfa_basic_recovery_code')) {
$data_plugins['tfa_recovery_code'] = 'tfa_recovery_code';
}Hello @bhanu951
Yes, recovery codes !
Indeed, I see that this handle by the module. Weird, during my tests, recovery codes wasn't migrated.
I am gonna close the thread for now and continue my tests.
Sorry for that.
$data_sms = (isset($decoded_data->sms)) ? boolval($decoded_data->sms) : FALSE;
fix the warning "[warning] Attempt to read property "sms" on array MigrateTfaUserSettings.php:98"
// If the user has TFA enabled, convert the enabled plugins from their
// Drupal 7 names and values to their Drupal 9 names and values.
if (isset($decoded_data->plugins)) {fix the warning : "[warning] Attempt to read property "plugins" on array MigrateTfaUserSettings.php:104"
Patch #6 works, thanks !
@bhanu951 : thank you, it works !
Thanks ! The patch works.
jibus → created an issue.
I have the exact same problem. I don't understand how to transfer files. I tried several path without success
So, instead of '/var/www/html/web-d7/sites/default/files' it probably should be '/var/www/html/web-d7/sites/default/files'.
Shouldn't be /var/www/html/web-d7 ?
@bhanu951, thank you for your answer.
Yes I am actually migrating an D7 instance with 1K users with TFA enabled.
I will let you know if I encounter any problem.
In the end, I switched from php 8.1 to 8.2 without any problem.
If you don't to push this, you can close the issue.
Thank you again.
#12 works for me !
#50 works also.
I would suggest to move the "Item wrapper node name" before "Item node name" configuration field.
Got error when enabled the module :
Drupal\Core\Config\UnsupportedDataTypeConfigException: Invalid data type in config auto_username.settings, found in file modules/contrib/auto_username/config/install/auto_username.settings.yml: The string "!php/const Drupal\auto_username\AutoUsernamePunctuationOptions::CASE_LEAVE_AS_IS" could not be parsed as a constant. Did you forget to pass the "Yaml::PARSE_CONSTANT" flag to the parser? at line 5 (near "aun_case: !php/const Drupal\auto_username\AutoUsernamePunctuationOptions::CASE_LEAVE_AS_IS") in Drupal\Core\Config\FileStorage->read() (line 118 of /var/www/lc.cx/web/core/lib/Drupal/Core/Config/FileStorage.php).
Set aun_case: 0 in auto_username.settings.yml fixed the issue.
Switch to major since this module cannot be installed.
Same issue here.
Attached patch
I encounter the same problem and the patch provided fixed the issue. Thanks
Yes, I saw this thread but it's not documented. Also, I think, the setup is not headless.
Oh I got it all wrong.
It seems that Google Chart (new) does not support QR Codes generation.
https://groups.google.com/g/google-visualization-api/c/77YEadph9JY
Same here, Google returns a 502 error.
Thank you ! Works as expected.
Drupal 7 will become EOL in 2025. Still can someone commit this ?
Does you dev env have access to internet and to the following URL ?
Looks like CF Turnstile return an unhandled error by the module.
From the module:
$error_codes = array(
'missing-input-secret' => t('The secret parameter was not passed.'),
'invalid-input-secret' => t('The secret parameter was invalid or did not exist.'),
'missing-input-response' => t('The response parameter was not passed.'),
'invalid-input-response' => t('The response parameter is invalid or has expired.'),
'bad-request' => t('The request was rejected because it was malformed.'),
'timeout-or-duplicate' => t('The response parameter has already been validated before.'),
'internal-error' => t('An internal error happened while validating the response. The request can be retried.'),
);
https://developers.cloudflare.com/turnstile/get-started/server-side-vali...
missing-input-secret The secret parameter was not passed.
invalid-input-secret The secret parameter was invalid or did not exist.
missing-input-response The response parameter was not passed.
invalid-input-response The response parameter is invalid or has expired.
invalid-widget-id The widget ID extracted from the parsed site secret key was invalid or did not exist.
invalid-parsed-secret The secret extracted from the parsed site secret key was invalid.
bad-request The request was rejected because it was malformed.
timeout-or-duplicate The response parameter has already been validated before.
internal-error An internal error happened while validating the response. The request can be retried.
So, it could be an invalid widget id or secret.
If you are in a dev env, you should only use dummy sitekey and secret.
Apart from the php version, I have the same Drupal version and I don't have the generic error.
Do you have Watchdog ON ? What does it say ?
Below my conf :
Default challenge type : Math (from module captcha)
Turnstile is set as challenge type on specific form id (for example contact form)
Default challenge on non-listed forms : DISABLED
Add CAPTCHA administration links to forms : DISABLED
Allow CAPTCHAs and CAPTCHA administration links on administrative pages : DISABLED
Default CAPTCHA validation : Case insensitive validation: lowercase/uppercase errors are ignored.
Persistence: Omit challenges in a multi-step/preview workflow once the user successfully responds to a challenge.
Enable statistics : FALSE
Log wrong answer : FALSE
This message is from CF, not the plugin.
Strange indeed.
Could you try to avoid setting Turnstile as default challenge for all forms and just enable it on the form you want (or one form for example)
Clear cache.
Doing that, do you have the same result ?
Do you have the same behavior when using the dummy sitekeys and secret keys ?
https://developers.cloudflare.com/turnstile/reference/testing/
Here you should now see the Turnstile widget loading
Does the widget display a green check icon ?
Hm that's a weird one..but at least it's fixed.
Both staged and production websites are set in French.
But looking at the database, the UID 1 and UID 0 language was set in EN.
Same thing for the fields : FR in staged, EN in production.
Other thing : on the staged website, each time i change the value of a field, a revision is created. This is not the case in production.
Finally, changing manually the language in database from EN to FR, values are now displayed.
Could it be about an initial english website then changing the language to french made this ? I don't remember how I installed this Drupal.
Closing this issue.
OK, I made some progress.
Looking at the database, the value is stored.
So the problem is on the display.
No, it's with user account fields (core).
Thank you. I will check.
The problem was noticed on 10.2.0, then I upgrade on 10.2.1 to see if there is any change.
Important note : I don't have this issue on my stage environment, only production where the configuration are sync.
re-rolled against current 7.x-1.x
Tested with Auth0 and worked.
Closing this since TFA disable the ability to login in through rest.
Greatmatter,
Thank you very much for taking the time on this. I already used it in production. I will let you know if its needs more fix.
Thanks you again !
Hi greatmatter,
50% of Drupal usage is still on D7. The EOL date you mentioning will be subject to discussion :
"Therefore, we are announcing that moving forward, the scheduled Drupal 7 End-of-Life date will be re-evaluated annually"
"We will announce by July 2023 whether we will extend Drupal 7 community support an additional year. Factors that we will consider are community support, Drupal 7 usage, and active Drupal 7 maintainers. Current support is made possible thanks to the many Drupal 7 maintainers and companies that are paying to support Drupal 7."
https://www.drupal.org/psa-2022-02-23 →
I won't insist on this as I understand you want to focus on the D10, but maybe leave in "Need review" in order to see if other people may be interested in this ?
Furthermore, it's not like this module will have tons of updates in the future.
Jibus → created an issue. See original summary → .