Problem/Motivation
#3410582: Optimize user logins by avoiding duplicate entity queries adds UserAuthenticationInterface to replace UserAuthInterface, but it doesn't yet deprecate the old interface because it would be a hard break for type hints of code relying on the current service. Instead we trigger runtime deprecations when we notice the new interface isn't in use, which should prompt contrib modules to update their UserAuth decorators to implement the new interface, and allow any code type hinting the old interface to update too.
Once we get to 11.1, we can assume that contrib should have updated and Drupal 10.2 support has been dropped. Then we can deprecate UserAuthInterface for removal in 12.x, and stop implementing it in the UserAuth class.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3427298
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
joseph.olstadList of contrib modules currently implementing the UserAuthInterface
There are likely many others. This list is a snapshot of search results found from the Russian drupal module grepper.
Comment #3
catch@joseph.olstad most of those are controllers and forms that are injecting the interface (and will be a one or two line change to update), not implementing it.
Comment #4
joseph.olstad@catch ,
ya, I was just curious as to how far this reaches. Then I thought that this list might be helpful. Especially for the working group that will be assembled for D11.
Comment #5
catchThis should be possible to do now.
Comment #8
longwaveBumping this to critical, given the implementation is going away in 12.0 we really should notify users ASAP, but 11.4 is now the earliest we can do that.
Comment #9
catchComment #13
cmlaraI suggest care in how the deprecation is handled and any associated messaging.
This isn't a common deprecation where maintainers can just change from
oldMethod()tonewMethod()prior to the method removal.There have already been bugs around contrib attempting to no longer support
UserAuthInterfacetoo soon.Until 12.0 all code needs to assume it will interact with
UserAuthInterfaceorUserAuthenticationInterface(and both in the same workflow due to decorators) .See https://www.drupal.org/project/tfa/issues/3497020#comment-15925291 for some previously written details regarding decorator interactions (and why TFA can not reliably implement
UserAuthenticationInterfaceuntil 12.0's release).Comment #14
berdirYes it is really tricky, I think we can only only triggering a deprecation in core when are dealing with a userAuth service that does not implement UserAuthenticationInterface. Core still actively implements this interface in \Drupal\user\UserAuthentication and will have to until that's no longer supported.
So in places like \Drupal\user\Form\UserLoginForm::validateAuthentication.
We also already trigger a deprecation in \Drupal\user\UserAuth::authenticate(), so anyone who still calls that already gets that.
In D12, \Drupal\user\UserAuthentication will then no longer implement UserAuthInterface and then we can deprecate the interface there for removal in D13.