Full Setup not working on 8.x-1.12

Thank you for the patch.

The patch file workflow has been deprecated on D.O. due to the upcoming decommissioning of DrupalCi on July 1st when DrupalCi will be fully replaced by GitLabCi.

Patch files can only be tested in DrupalCi while MR’s can be tested in both DrupalCi and GitLabCi. This means after July 1st only MR’s will be testable on Drupal.org.

Many modules, including TFA, have already adopted GitLab CI in order to be prepared for decommissioning. Part of the adoption processes involves disabling DrupalCi to conserve resources.

Due to above reasons the TFA project can only work with MR’s and will need the patch file converted to a MR to continue.

Hi, I can confirm that the code in the patch fixes the problem, after updating the form manually. I am unable to apply the patch to the latest release (8.x-1.11) though. Also if I recall correctly it could not be applied to the previous release 8.x-1.10 either. Please can you fix this for the next release though? Much appreciated!

I've updated the priority for this issue to Critical, owing to the fact that when the bug occurs it completely stops the TFA module from working.

Merged latest from 8.x-1.x

Can confirm that the update fixes the issue when multiple plugins are used.

Note that the MR pipeline failures re-phpstan and phpunit errors are not related to this change and come from 8.x-1.x; those should probably be fixed as part of a separate issue.

The MR now applies to the last release (1.12)

Confirming this on 8.x-1.12 as well !

Root cause matches the summary here: in TfaSetupForm::buildForm(), when the
multi-step flow overrides $method from $storage['step_method'],
$setup_plugin_id is not re-resolved. It keeps the first step's setup plugin id
(e.g. tfa_totp_setup), so advancing re-instantiates the TOTP setup plugin and
regenerates the seed. The user is shown the TOTP form again and the second
submit fails ("Invalid application code...") because the earlier code is
validated against a brand new seed.

MR !163 resolves this for us: after re-resolving the setup plugin from
step_method, the second QR scan no longer appears. We confirm it applies
cleanly to 8.x-1.12 and fixes the issue whenever the full-setup sequence has
more than one step (a validation plugin plus a login plugin such as
tfa_trusted_browser); single-plugin setups don't hit it.

One small thing worth a look before merge: MR !163 moves the plugin-existence
guard (findPlugin() / hasDefinition() / NotFoundHttpException) from the top of
buildForm() into the step-rendering section. That correctly fixes the bug, but
it also defers the invalid-$method 404 that previously fired at function entry,
so it may be worth confirming the not-found behaviour for a bad {method} route
argument still holds on the early (pre-confirmation) paths.

+1 to getting MR !163 into a release.

MR !163 applies cleanly to 8.x-1.12 and fixes the step rendering. Confirmed
with the email OTP plugin as default: the trusted browser step now renders its
own form instead of repeating the first step.

One note on https://www.drupal.org/project/tfa/issues/3534403, which was closed as a duplicate of this issue. It
reported two symptoms and this MR covers the first. The second is that every
intermediate step announces 'TFA setup complete.' next to 'One setup step
remaining.', which has a separate cause: the guard in
`TfaSetupForm::submitForm()` tests `getRebuildInfo()` where
`tfaNextSetupStep()` called `setRebuild()`.

I have filed that separately as https://www.drupal.org/project/tfa/issues/3620510 so it does not hold up this MR.

We should try and get some test coverage in for this.

I'm unable to reproduce this on a fresh install. Can someone please update the IS with the full set of steps.

What I tried:
1. Install standard profile on 11.4
2. Enable TFA, Encrypt, Key modules
3. Configure encryption profile
4. Enable TFA with default settings, and enable "TFA Recovery Code" and "TFA Time-based one-time password (TOTP)" validation plugins, and require setup for authenticated users
5. Create a new user
6. Login as user and follow error message link to setup tfa
7. Configure TFA for user
8. Enable recovery codes
9. Test login with user

Everything seemed to work fine.

EDIT: Got it working, you need to enable the trusted browser login plugin to get the 2 step process.

Added test coverage and confirmed #20 was a valid concern. I've fixed that and added test coverage for that as well.