Implement Drupal\user\UserAuthenticationInterface

Until Drupal 12 is released contrib modules need to accept both interfaces and test which they have been provided. See #3456738: BC break in login auth changes from #3444978 comments #22 and #24.

Mail_login should indicate it is only compatible with Drupal12+ if it accepts only the newer interface, otherwise it needs to accept both. You likely will want to raise a bug report in mail_login to inform them of this issue.

Setting to a task as we will eventually need to do this. Moving to needs-work as D.O. has fully moved over to an MR only workflow, patches can not be tested only MR’s can be tested/reviewed.

Edit: to note that accepting only the older Interface is acceptable in Drupal < 12.

From the MR

UserAuthenticationInterface::lookupAccount() does not exist in decorators not implementing UserAuthenticationInterface.

Core's user login form assumes that if the User Auth service implements UserAuthenticationInterface it is safe to call lookupAccount.
This works fine when you have only the two sceanrios:

• Core Login Form -> Core UserAuth service (implements UserAuthenticationInterface)
• Core Login Form -> Decorator1(UserAuthenticationInterface) -> Core UserAuth(UserAuthenticationInterface)
• Core Login Form -> Decorator1(UserAuthenticationInterface) -> Decorator2(UserAuthenticationInterface) -> Core UserAuth(UserAuthenticationInterface)

This logic however fails when you have

• Core Login Form -> Decorator1(UserAuthenticationInterface) -> Decorator2(UserAuthInterface) -> Core UserAuth(UserAuthenticationInterface)
• Core Login Form -> Decorator1(UserAuthenticationInterface) -> Decorator2(UserAuthInterface) -> Decorator3(UserAuthenticationInterface) -> Core UserAuth(UserAuthenticationInterface)

The outcomes in this scenario are that core calls Decorator1 and:

• Decorator 1 calls non-existent method on Decorator2 (throws an exception) or
• Decorator 1 attempts to resolve the data itself using Cores logic ( this is a breach of decorator design, and would mask that Decorator3 is being ignored)

I will note the first scenario is essentialy what you describe in #6, where mail_login was re-written to (incorrectly) assume every decorator will already implement UserAuthenticationInterface prior to D12, possibly because core made the same assumption.

On a cursory glance I believe the only way we can use UserAuthenticationInterface is if we are on D12, OR we have a setting that manually enables the use of a new class when a site owner ensures 100% of their stack supports the UserAuthenticationInterface (in which case it is safe for exceptions to be thrown).

Drupal Core tried to do this in a manner to retain BC with minimal immediate contrib breakage and ended up creating a scenario that the probability of site breakage increased each day the commit remained in the repository by pushing design failures onto the contrib ecosystem. When we look at the entire issue as a whole we are essentially left with a non BC capable API addition that would have been easier to implement if it was mandatory.

But log in works only with username, if TFA is enabled and I try to log in via email, it's not working.

But log in works only with username, if TFA is enabled and I try to log in via email, it's not working.

Assuming this is related to this interface, see #8 and the associated MR comment.

Essentially, until D12 any Core or Contrib code needs to assume that lookupAccount() doesn't exist and code around it to implement their features Some Contrib or Core may not have properly done this, you would want to check with whatever module is providing Email address support as the root cause.