-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
UsageTrackingTokenStorage deprecation is Security.php #43042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
When are you calling this helper? Looking at the deprecation, it only gets triggered if |
This service is basically called in a controller before to create a view. |
Can you provide a reproducer? We will need that to help. |
I guess i have found the issue. The Security service is called from a kernel event listener (kernel.terminate) and not only from a simple service. |
use the untracked storage in that listener |
could you please provide some details to do that ? thank u |
Use the |
The container is not injected in this listener. So i can't access to security.untracked_token_storage from this listener. |
Workaround found.
Many thanks ! |
I've got similar deprecation triggered when using the /**
* Adds user information to a record.
*/
class UserProcessor implements ProcessorInterface
{
public function __construct(private Security $security) {}
public function __invoke(array $record): array
{
$user = $this->security->getUser();
if (!$user) {
return $record;
}
if (method_exists($user, 'getUserIdentifier')) {
$record['username'] = $user->getUserIdentifier();
} else {
$record['username'] = $user->getUsername();
}
return $record;
}
} We can not call The only solution is to inject
|
I think the helper should handle this case internally: #43235 |
I'm wondering whether the helper should handle this, or whether UsageTrackingTokenStorage should instead accept getting a token from it outside request contexts. |
Same feeling for me.. Removing the deprecation (and let the method returning |
If we can get rid of that notice while keeping the BC layer efficient enough, I'm all for removing it. I'm going to investigate |
…kenStorage` (chalasr) This PR was merged into the 5.3 branch. Discussion ---------- [Security] Remove annoying deprecation in `UsageTrackingTokenStorage` | Q | A | ------------- | --- | Branch? | 5.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #43042 | License | MIT | Doc PR | - Commits ------- 06f4663 [Security] Remove annoying deprecation in `UsageTrackingTokenStorage`
Symfony version(s) affected: 5.3.7
Description
After using $security->getUser() in a service as mentioned in the documentation (https://symfony.com/doc/5.4/security.html#a-fetching-the-user-object) i get a deprecation warning :
"Since symfony/security-core 5.3: Using "Symfony\Component\Security\Core\Authentication\Token\Storage\UsageTrackingTokenStorage" (service ID: "security.token_storage") outside the request-response cycle is deprecated, use the "Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage" class (service ID: "security.untracked_token_storage") instead or disable usage tracking using "disableUsageTracking()""
How to reproduce
To reproduce this issue, create a service that use Security and call $security->getUser() :
`use Symfony\Component\Security\Core\Security;
class MyService{
}`
Possible Solution
I find out that Security.php of the core security component is using a deprecated service :
public function getToken(): ?TokenInterface { return $this->container->get('security.token_storage')->getToken(); }
As mentioned in the deprecation notice it seems that the service "security.token_storage" should be replaced by "security.untracked_token_storage".
Thanks for your feedback !
The text was updated successfully, but these errors were encountered: