Allow modules to skip TFA through a hook

Created on 8 May 2024, 11 months ago

Problem/Motivation

Currently TFA can be setup based on user roles. It would be very helpful to have a more granular control over which users need to use TFA. I have a project, where group roles (Group contrib module) have more relevance than user roles. Opening an API hook to allow other modules define in their own logic and context when TFA is to be used or skipped, without the need to create a custom plugin.

Steps to reproduce

Try to setup TFA based on anything other than user roles.

Proposed resolution

Create a hook for other modules to use in order to skip TFA according to their custom logic.

Remaining tasks

Tests

User interface changes

None

API changes

Yes, API file and hook invocation provided in the patch.

Data model changes

None

✨ Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇦🇹Austria jordik

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jordik
  • 🇦🇹Austria jordik
  • 🇺🇸United States cmlara

    It appears this may be a duplicate of ✨ Allow TFA requirement to be configured per user Needs work . Can you confirm it is not before this continues further?

    Feature requests should target 2.x first.

    The patch file workflow has been deprecated on D.O. due to the upcoming decommissioning of DrupalCi which is being replaced by GitLabCi.

    Patch files can only be tested in DrupalCi while MR’s can be tested in both DrupalCi and GitLabCi

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

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

  • 🇦🇹Austria jordik

    Thank you for the sift reaction, @cmlara!

    As far as I get the intention from looking at ✨ Allow TFA requirement to be configured per user Needs work it is solving a similar problem in a much more complicated way. I personally find the hook approach much easier and slightly better documented. It is in line with the comment #4 in the related issue.
    I was also thinking of showing a list of modules in the TFA configuration, which use this hook. In this way admins can recognize at a glance if the TFA can be potentially skipped.

    As for the second part of your comment - I will open a MR for 2.x-dev.

  • Status changed to Closed: duplicate 11 months ago
  • 🇺🇸United States cmlara

    it is solving a similar problem in a much more complicated way. I personally find the hook approach much easier and slightly better documented

    If the primary difference is hook vs event that should also be discussed in the other issue. Events however are the way forward. Hooks are an outdated Drupalism that the current effort is to remove from code rather than adding new hooks.

    Documentation is usually an implementation fault (failure to document when creating the emitter) and TFA has recently adopted GitLab Pages to help handle this.

    The idea of showing implementers is not a bad idea, part of me was previously thinking that an interactive tester would also be useful however I was not going to force it as a requirement to add the feature.

    I can’t see this issue being able to work without needing to undertake the same work as ✨ Allow TFA requirement to be configured per user Needs work . I’m going to close this as a duplicate.

  • 🇦🇹Austria jordik

    Re-roll to TFA 1.8

  • 🇦🇹Austria jordik

    Re-roll to TFA 1.8 - patch in #6 is wrong.

  • 🇺🇸United States dianacastillo Miami

    this last patch -7 does not apply with the 2x.dev version .

Production build 0.71.5 2024