Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[POC][Security] Introduce GuardAuthenticationManager to make guards first-class security #33558
This is a first PR to kick-start Security improvements. @weaverryan and I have discussed the best steps and we think these changes offer the best experience with the least amount of work for Symfony users.
migrate everything in Security to be "Guard" instead of the current providers/listeners/handlers.
This PR creates a new
After this PR (and possibly during the whole 5.x release cycle), Security needs more changes:
I recently had a scenario where I get a user if passed with an authenticated jwt token. I should create a user entity if it missing (by using data in auth0), if email is valid I create an authenticated token, if not, I will ask the user to login (with different authenticator).
I was not able to write a nice solution with guard for this scenario, so I had to use the “low level code”.
I’m all for promoting guard and trying to make it better, but I think it would be use the more flexible solution when needed.
Hmm, interesting. Our assumption has always been that Guard is not less flexible than the current listener-provider solution. Guard only combines them into one class, which makes it more difficult to reuse partial systems (i.e. the DaoAuthenticationProvider).
I do not fully follow your requirements, but it would be interesting to see whether or not Guard (or a modification in Guard) could have fixed your requirements.
For now, I would say it doesn't matter as this PR is not about deprecating the old system. It's only introducing a new system next to it, to allow experimenting (and discovering exactly cases like you mentioned). For that reason, it's maybe a good idea to mark the new classes as
In order to be usable a class should as of now implement both interfaces, so the
This is an iteration on the AuthenticatorInterface of the Guard, to allow more flexibility so it can be used as a real replaced of the authentication providers and listeners.
This is required to create the correct authenticated token in the GuardAuthenticationManager.
This removes the introduced dependency on Guard from core. It also allows an easier migration path, as the complete Guard subcomponent can now be deprecated later in the 5.x life.
This allows more flexibility for the authentication manager (to e.g. implement login throttling, easier remember me, etc). It is also a known design pattern in Symfony HttpKernel.
This to remove confusion between the new system and Guard. When using the new system, guard should not be installed. Guard did however influence the idea behind the new system. Thus keeping the mentions of "guard" makes it confusing to use the new system.