Problem/Motivation
Despite past efforts to convert the session as well as the user authentication subsystems to OO code, the current status of both is still insufficient for release. This is likely due to both subsystems being worked on in separate efforts. However, for historical reasons sessions are hard-wired to user authentication and vice versa. This issue provides the big picture and a roadmap outlining the steps necessary to separate both subsystems and finalize the API for session and user authentication.
The most prominent sign of the current defects in both components is the presence of the global $user:
git grep -l -i 'global.*user'
Authentication/AuthenticationManager.php
Authentication/Provider/Cookie.php
Routing/Enhancer/AuthenticationEnhancer.php
Session/AccountInterface.php
Session/SessionHandler.php
Session/SessionManager.php
Session/SessionManagerInterface.php
Session/UserSession.php
Step 1: Remove the dependency of AccountProxy on AuthenticationManager
The AccountProxy currently triggers authentication automatically whenever one of the methods of the current_user service is accessed. As a result it has a dependency on the AuthenticationManager which is responsible for checking credentials on an incoming request and based on that setting the current user. This circular dependency is hidden because the AuthenticationManager acts on the global $user.
Thus in order to remove the global $user from AuthenticationManager, it is necessary to first remove automatic authentication from AccountProxy.
Issues which need to be resolved:
This also will fix:
User interface changes: None
API changes: Reverse dependency between AuthenticationManager and AccountProxy.
Expected impact on core and contrib code: Minor
Step 2: Register symfony session components in the DIC and inject the session service into the request object
Can and should be resolved in parallel to Step 1.
In Symfony based applications, the session is an object on the request. However, in Drupal services wishing to control the session currently do so by invoking methods on SessionManager. This is appropriate as a temporary solution. However, in order to maintain interoperability the final API should conform to what Symfony components expect.
NB: Whether the session will still be accessible from the DIC or only from the request in Symfony 3.0 is currently under discussion, (see [Symfony 3.0][RFC] The session must not be a service #10557).
User interface changes: None
API changes: Access and control the session by $request->getSession() (API Addition).
Expected impact on core and contrib code: Minor
Step 3: Remove user authentication related code from the session component (and remove global $user)
Based on the previous steps, user authentication can be separated completely from sessions by assigning the responsibility for loading and setting the current user to the authentication provider.
#2228393: Decouple session from cookie based user authentication →
User interface changes: None
API changes: None
Expected impact on core and contrib code: Minor
Step 4: Audit session and user authentication components
Steps 1-3 block:
