[Security] Add authentication success sensitive event to authentication provider manager (rebase #26050) #30955
Conversation
…on provider manager
src/Symfony/Component/Security/Core/Event/AuthenticationSensitiveEvent.php
Outdated
Show resolved
Hide resolved
| use Symfony\Component\Security\Core\Authentication\Token\TokenInterface; | ||
| use Symfony\Contracts\EventDispatcher\Event; |
There was a problem hiding this comment.
should be reverted: BC break :)
| private $authenticationToken; | ||
| private $authenticationProviderClassName; | ||
|
|
||
| public function __construct(TokenInterface $preAuthenticationToken, TokenInterface $authenticationToken, ?string $authenticationProviderClassName = null) |
There was a problem hiding this comment.
please remove the? as our CS is to consider the null default means the same (it does)
| * | ||
| * @return string|null Either a credentials password/secret/auth_key is returned or null on extraction failure | ||
| */ | ||
| public function getAuthenticationTokenPassword(?\Closure $extractor = null): ?string |
|
|
||
| private function tryCoercibleCredentialsPasswordToString($credentials): ?string | ||
| { | ||
| return is_scalar($credentials) || method_exists($credentials, '__toString') |
There was a problem hiding this comment.
should be on one line as we usually prefer long line in similar cases
| }; | ||
| }; | ||
|
|
||
| $createHasStrCastableClass = function (?string $return = null) { |
|
Get me my headset back and I'll sort the mess out again 😄 |
|
Event names are usually very descriptive ... so I find this new event name ( |
|
@javiereguiluz fair point but I don't really see an alternative. Technically it IS the authentication success event, just called a second time before we do I'll take any suggestions here... |
|
Isn't Symfony getting rid of event names anyway? So the event name should simply be the event class name? |
|
@aschempp correct but it would be inconsistent right now to follow that convention for the new event, and major B/C breakage to adapt all the others. So in core that's a job for later on. |
|
I agree that we cannot remove the old ones, but there is no need to create a new one. People will eventually remove usage of the current names, so the inconsistency is not a problem IMHO. |
|
Fair enough, and just thinking some more about the name => how about It conveys that we do not yet consider the Authentication a success (because if you throw inside the Accepted it will fail still) but that we can confirm we are about to, and as such this is the time to do last call on the token that was accepted before we clean it up. |
|
Maybe |
|
As credentials are part of the token it would then have to be |
I'm not sure we are: core should be much more explicit than what is allowed for not-core. E.g. autowiring is not a feature we use in core. |
|
oh, but the new event should be listed in |
|
Thinking a bit about this approach, I have a different one to propose, see #31139 |
|
@wouterj do you think this proposal fits well with the latest changes you are proposing in the Security component or is it unrelated? Thanks! |
|
It's a bit hard to follow, as the discussion was inside multiple PRs and issues (#26050, #31139, #31843, #18494), but as far as I can see this PR is no longer needed. #31843 build another approach to rehash passwords that was merged into 4.3 (https://symfony.com/blog/new-in-symfony-4-3-native-password-encoder). As far as I can see, rehashing credentials was the only reason for this event to exists. |
|
As said, password rehashing is now supported. I'm going to close here until another use case comes out. Thank you @robfrawley and @curry684 |
Rebased #26050 at EUFOSSA
Thanks @robfrawley for the excellent work!