[Security] Use supportsClass in addition to UnsupportedUserException #35065
Conversation
|
One additional solution for 3.4 and higher in case we want to add the BC version, would be to log it as error regardless so that people can fix it without introducing a new feature: try {
$refreshedUser = $provider->refreshUser($user);
$newToken = clone $token;
$newToken->setUser($refreshedUser);
if (!$provider->supportsClass($userClass)) {
$this->logger->error('...');
}Both failures are unrelated to this PR as far as I can see. |
|
I would consider the new error log a feature :) I think we can just fix the non called |
|
So if I understand it correctly, the PR as-is is okay? I'm not sure what the best approach would be for 5.1 and 6.0. Ideally I'd see either What about a |
| @@ -168,12 +168,17 @@ protected function refreshUser(TokenInterface $token) | |||
|
|
|||
| $userNotFoundByProvider = false; | |||
| $userDeauthenticated = false; | |||
| $userClass = \get_class($user); | |||
There was a problem hiding this comment.
not needed, opcache does a better job without it
There was a problem hiding this comment.
You have some resources on that?
There was a problem hiding this comment.
you mean inlining the call instead of using a variable? I won't make a claim here, I'm fine this way :)
There was a problem hiding this comment.
I know that importing certain functions from the root namespace gives an optimization for these functions, never heard of it being the other way around, hence I'm curious 😄
|
|
Thank you @linaori. |
…rException (linaori) This PR was merged into the 3.4 branch. Discussion ---------- [Security] Use supportsClass in addition to UnsupportedUserException | Q | A | ------------- | --- | Branch? | 3.4+ | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #35045 | License | MIT | Doc PR | ~ This PR fixes the issue where user providers rely on just the UnsupportedUserException from `refreshUser()`, causing a flow where users are wrongfully re-authenticated. There's one issue where `refreshUser()` can do far more sophisticated checks on the user class, which it will never reach if the class is not supported. As far as I know it was never intended to support instances that are rejected by `supportsClass()`, though people could've implemented this (by accident). So the question is more if we should add a BC layer for this; for example: ```php try { $refreshedUser = $provider->refreshUser($user); $newToken = clone $token; $newToken->setUser($refreshedUser); if (!$provider->supportsClass($userClass)) { if ($this->shouldCheckSupportsClass) { continue; } // have to think of a proper deprecation here for 6.0 @trigger_error('Provider %s does not support user class %s via supportsClass() while it does support it via refreshUser .. please set option X and fix %s::supportsUser() ', E_USER_DEPRECATED); } ``` This would prevent behavior from breaking but also means we can't fix this on anything less than 5.1. Commits ------- d3942cb Use supportsClass where possible
This PR fixes the issue where user providers rely on just the UnsupportedUserException from
refreshUser(), causing a flow where users are wrongfully re-authenticated.There's one issue where
refreshUser()can do far more sophisticated checks on the user class, which it will never reach if the class is not supported. As far as I know it was never intended to support instances that are rejected bysupportsClass(), though people could've implemented this (by accident). So the question is more if we should add a BC layer for this; for example:This would prevent behavior from breaking but also means we can't fix this on anything less than 5.1.