This is security-related, so we'd like to merge this as soon as possible.@wouterj could you please check these proposed changes? Thanks!

What if we simply do not show the use of multiple attributes here, but use an expression which checks if the user is granted at least one of them to avoid the ambiguity here?

What if we simply do not show the use of multiple attributes here, but use an expression which checks if the user is granted at least one of them to avoid the ambiguity here?

The main problem for me is that in YAML and PHP configuration formats, the key is calledroles instead ofrole so I prefer to have it properly documented.

Maybe we could add an advice to use an expressión and avoid further problems.

After#15503 is merged, we'll need to check if this is still relevant and if we need to fix it. Thanks!

After#15503 is merged, we'll need to check if this is still relevant and if we need to fix it. Thanks!

@javiereguiluz#15503 is merged and I think this is still relevant. I've rebased the PR.

Hi@ajgarlag!

I'm sorry for the long wait here. I honestly wasn't sure what to do with these changes, as I do see your point about "roles" (and also being able to pass an array of attributes to this setting).

For now, I've decided to follow@xabbuh's suggestion. The reason is that an array of roles does not have a strict OR or AND relation, nor does this depend on the strategy. For full information:

• The strategy determines how the votes of all voters are merged. E.g.RoleVoter might return DENIED, whereasAuthenticatedVoter returns GRANTED.
• However, the list or roles is provided to each voter and the voter itself determines how to turn the list of roles into a single vote. So if you have multiple attributes that are handled by the same voter (e.g. 2ROLE_* attributes), the strategy is no longer important and the relationship is hardcoded in the voter (in the case of roles without using role_hierarchy, it's OR).
• For roles, this becomes even more confusing as plain roles are handled byRoleVoter, but hierarchical roles are handled byRoleHierarchyVoter. So if a ROLE_ADMIN is also a ROLE_USER (through the hierarchy) and you use['ROLE_USER', 'ROLE_ADMIN'], you end up with a completely confusing situation (where both voters merge the attributes into a single vote using hardcoded logic, and the Access decision manager merges the two votes based on the strategy).

This is exactly the reason why we removed voting on more than one attribute at the same time. Unfortunately, it's the worst change I've ever contributed to Symfony (implementation wise), which means we still have the "roles" setting and ability to use an array of roles inaccess_control. Let's see if we can fix this for 6.x :)

Anyway, in case you're still reading this message: Thanks for remaining active in this PR! If you have any questions, feel free to comment :)