Create "Email one-time-code" Validation Plugin & related Setup Plugin

The patch fixes the bug mentioned in #59 and #40.

Difference between patch #54 and #60.

@Mingsong, I know you are using this with 8.x-1.x. This feature will never be added to the 1.x branch. You're free to not want to update it to 2.x, but please don't put it back in "Needs Review" if it is not compatible with 2.x, as I'll simply put it back to "Needs work" until your comments mention that the patch is now ready for 2.x.

@João Ventura, thanks for the heads up. We will need the 2.x at some point in the future, as 8.x-1.x will not be supported after Drupal 9.

No problem. Understand that 1.x is bug fixing only.

I can help this issue for 2.x branch as well. But at this stage, 2.x branch is just not stable enough to integrate this plugin.

@Mingsong thank you for the patch tfa-2930541-60.patch. However, I still see the bug mentioned in #40 and #59. I am on 8.x-1.0. Here are the steps.

1. Login on a new browser session.
2. On TFA page, enter the authentication code from the email, select "Remember this browser for 30 days?" and verify.
3. Logout from the website.
4. Login again in the same browser session.
5. The user is logged in without TFA page and shows the message "You have logged in on a trusted browser.".
6. However, the authentication code for the 2nd login is sent to the email.

Thanks for looking into this.

Thanks @Naveen for testing the patch.

As in our use cases, the 'Trusted browser" is not allowed. So we didn't test this scenario.

The problem comes from the fix for bug mentioned in #47.

The easy fix for this bug is to change the button from 'Resend' to 'Send', and the user has to click the button at least once.

In this way, we don't modify the logic and login process of TFA, otherwise it will require a lots of testing and might be not work with other custom plugins provided by another modules.

Here is the new patch.

Changes between patch #60 and #66.

Here's an updated plugin that sends the user the email when the form loads, tracks the send in the state expire system and posts a message to the user letting them know what's going on.

Sorry, I messed up the previous patch.

Here's a corrected one without parts missing. I also added a cleanup on the state var once the code is validated (in case the user logs in / out quickly before the code expires).

@minorOffense, thanks for providing the patch. I tested it and found an issue in the following scenario.

Here are the steps.

1. Login on a new browser session.
2. On TFA page, enter the authentication code from the email, DON'T select "Remember this browser for 30 days?" and verify.
3. Logout from the website.
4. Login again in the same browser session.
5. The user is prompted for the authentication code on the TFA page, but the email with the code is not automatically sent. I had to click "Send" to get the email.

It's working fine for other scenarios when selecting to remember the browser for 30 days.

Thanks for looking into this.

I think this is still a task (really feature) that needs work.

If you disagree please explain why as you change the category and status.

Patch for 2.x branch.

I will work on the test for the new feature.

Patch #73 has some bugs.
Here is the new patch without having PHPUnit test.

The patch for 2.x branch with a new test.

Patch #73 and #74 is out of date.

Since the patch for 2.x is provided, I put this issue to 'Needs review'.

Please feel free to correct me if I was wrong.

Thanks for this Mingsong. I'll try to test this soon(ish). Would be good to see some of the others in this thread also test this.

Tested patch #75. With this new behavior when code is sent only after clicking "Send" button, the hint text under the code box
"The authentication code has been sent to your registered email. Check your email and enter the code."
is not correct anymore, since the code is not being sent initially.
I would suggest to change it to Status message area instead of embedded in the form as of now. Attaching a patch with this change.

Thanks @Laziz,

FYI, the changes between patch #75 and #79 is

diff --git a/src/Plugin/Tfa/TfaEmailCode.php b/src/Plugin/Tfa/TfaEmailCode.php
index 6e0e0cd..52e5b26 100644
--- a/src/Plugin/Tfa/TfaEmailCode.php
+++ b/src/Plugin/Tfa/TfaEmailCode.php
@@ -217,6 +217,9 @@ class TfaEmailCode extends TfaBasePlugin implements TfaValidationInterface, TfaS
         '@email' => $this->recipient->getEmail(),
       ]));
     }
+    else {
+        \Drupal::messenger()->addMessage(t('The authentication code has been sent to your registered email. Check your email and enter the code.'));
+    }
 
     $this->isSent = TRUE;
   }
@@ -228,9 +231,9 @@ class TfaEmailCode extends TfaBasePlugin implements TfaValidationInterface, TfaS
 
     $form['code'] = [
       '#type' => 'textfield',
-      '#title' => $this->t('Enter the received code'),
+      '#title' => $this->t('Authentication code'),
       '#required' => TRUE,
-      '#description' => $this->t('The authentication code has been sent to your registered email. Check your email and enter the code.'),
+      '#description' => $this->t('Enter the code received'),
       '#attributes' => ['autocomplete' => 'off'],
     ];
     $form['actions']['#type'] = 'actions';

Refresh the patch for 8.x-1.1.0.

Hiding remaining 1.x patches as #46 converted this to a 2.x issue.

There is no need to upload new 1.x patches until the 2.x patch is accepted and the previous decision of this being a 2.x only issue has been reverted.

If you are uploading 1.x patches here that are intended for used in your own local deployment please keep those patches on your own server to avoid unnecessary posts into the issue history.

Hi @Conrad,

I understand this issue has been ported to 2.x. However we can't use TFA 2.x for our production sites until a stable release which is covered by Drupal security advisory.

The patch uploaded here for 8.x-1.1 is not for testing purpose, but for production patching via composer.

It is generally recommended to not depend on production patches being hosted on D.O.. Patches should instead be kept somewhere 'local'.

I would also recommend sites not use work in progress patches in production. The patches in this issue may change at any time, security faults may be disclosed without any resolution, and compatibility may break in any new iteration.

With the most recent TFA update (8.x-1.4 Stable release, released 29 November 2023), our users are getting multiple emails from the email plugin, and the codes don't seem to work. The patch seemed to be applied. Is anyone else having this issue?

It has been 6 years.

I think it is time to have a contribute module for this feature.

https://www.drupal.org/project/tfa_email_otp →

Seems fair to move this to contrib.

I will leave this issue open until a release is made and than close as outdated.

Glancing at https://www.drupal.org/project/tfa/ecosystem → I don't see the module listed. I would encourage updating the module so that it appears as part of the TFA ecosystem so others can more easily discover it.

Thanks @Conrad.

I was confused by the module name. There are multiple module ecosystems call 'Two Factor Authentication'.

I think I got it right now.

@Conrad, first release is out. You can close this issue now if you like.

Thank you for the update @Mingsong!

Looks like good progress in bringing this forward as a community module.

@MingSong Well done! I was looking for an email OTP to replace the functionality of tfa_basic that we were using on D7.

Installed your plugin module to a site using 1.5 of TFA and it works a treat. Thank you!

Reroll from #79 for latest 2.x version of TFA module

Replaced usage of $this->langCode to $this->recipient->getPreferredLangcode(), because of error

Error : Typed property Drupal\tfa\Plugin\Tfa\TfaEmailCode::$langCode must not be accessed before initialization dans Drupal\tfa\Plugin\Tfa\TfaEmailCode->begin() (ligne 206 de /var/www/html/web/modules/contrib/tfa/src/Plugin/Tfa/TfaEmailCode.php).