Security is_granted annotation not working with new PUBLIC_ACCESS role

[aless673]

The user with role PUBLIC_ACCESS cannot access a route annotated with @Security("is_granted('something')").

Extra informations :

1. It does not even enter the Voter
2. Testing inside a controller the $this->isGranted('something') is correctly working

[derrabus]

Can you create a small repoducer application?

[aless673]

Repo : https://github.com/aless673/sensio_security_annotation_bug

Steps:

1. Run symfony server:start
2. Access http://127.0.0.1:8000/ => redirect to login page (OK)
3. Access http://127.0.0.1:8000/test => access to test page (OK)
4. Access http://127.0.0.1:8000/test_bug => redirect to login page (should not)

test is protected inside the action with $this->denyAccessUnlessGranted('canAccess') test_bug is protected with Security annotation @Security("is_granted('canAccess')") canAccess always return true

[blibio]

I had the same issue when upgrading Symfony from 5.2 to 5.3.

While digging around I found that this line:

https://github.com/sensiolabs/SensioFrameworkExtraBundle/blob/403ad8f44160c6f943d73840519e8c50a03363cc/src/EventListener/SecurityListener.php#L66

Would force a redirect to my login page before consulting my custom voter.

---

Checking similar parts in the sf security component, one can see that the new NullToken is created instead (provided exceptionOnNoToken is not set):

https://github.com/symfony/symfony/blob/c71c8727cc665c9e9b56e299fcfcc0adfbf02bac/src/Symfony/Component/Security/Core/Authorization/AuthorizationChecker.php#L56

https://github.com/symfony/symfony/blob/c71c8727cc665c9e9b56e299fcfcc0adfbf02bac/src/Symfony/Component/Security/Http/Firewall/AccessListener.php#L91

As a work around I switched from the @Security("is_granted(...)") to the @IsGranted(...) annotation, which solved the problem for the moment.

I hope this might help to address the issue!

[stof]

the issue is that @Security() reimplements some of the logic of the authorization checker on its own (as it is not always calling the AuthorizationChecker). So it might need to be updated to account for new behavior. The @IsGranted annotation was introduced precisely to avoid that design flaw.

[AurelC2G]

Ran into the same problem, I'm using the @Security annotation with an expression that doesn't require an authenticated error, which used to work with anonymous users but doesn't anymore after enabling the new security system (the expression doesn't get executed, it fails before reaching it).

[Alsatian67]

I think we could change the listener to just set the token and user variables to null when getToken() == null, and roles to [] ?

And then, remove the condition throwing the AccessDeniedException.

But I am wondering if 'token' is till relevant for sf >= 5.3 ?