Yep, I got your thought, but what about inconsistency in parameters definition? I mean in some places $attributes are mixed and in some string?

imho - roles - is closed lists.

It's rarely the case when building application with a complex or dynamic role system

With match expressions now supporting exhaustive match hinting in some IDEs.

And bits of code like this common in custom voters.

protected function supports($attribute, $subject) {
        $validChecks = [self::REVIEW, self::PAYMENT, self::REFUND, self::CANCEL, self::MODIFY, self::THANK];

        if(!in_array($attribute, $validChecks)) {
            return false;
        }

Attributes allowing the support of enum values.

Supporting enums in voters is clear improvement.

@tarlepp in your specific project, it likely is a closed list. But in symfony/security-core, it is not.
Each project using Symfony will want to have their own list of roles, not a closed list defined in symfony/security-core.

Accepting stringable won't help you, as enums cannot be stringable.

Enums provide a benefit to avoid errors when you can use them as the type of parameters to restrict things. But the AuthorizationCheckerInterface cannot use such application-specific enum as its parameter type, as it cannot depend on it.

PHP enums are representing a type with a closed list of values. But as far as symfony/security-core is concerned, permissions are an open list (which is what allows you to define your own permissions in your application) and so enums are not the right fit for that.

@stof Christophe, sorry, but I still don't understand your point. I like the DRY principle (as many do, I bet). So in my app I have a set of permissions like that:

enum ProjectPermission: string
{
    case View = 'view';
    case MarkAsDone = 'markAsDone';
}

To me it's a closed set of options, if I need more, I'll add, but it's pertinent to one entity and it's not open.
So in my voter I did (it doesn't work, hence I googled for this discussion):

    protected function supports(string $attribute, mixed $subject): bool
    {
        return in_array($attribute, ProjectPermission::cases(), true) && $subject instanceof Project;
    }

And, returning to the DRY principle, in my controller I could do:

    #[Route('/{slug}', name: 'project_view', methods: ['GET'])]
    public function view(string $slug, Request $request, ProjectRepository $projectRepository): Response
    {
        $project = $projectRepository->findBySlug($slug);

        if (!$project || !$this->isGranted(ProjectPermission::View, $project)) {
            throw $this->createNotFoundException('This project does not exist');
        }

return $this->render('project/view.html.twig', [
            'project' => $project,
        ]);
    }

I think it's beautiful and clean. However, without enums I need to use constants, then do an array of all the constants for calling in_array in the supports() method, then use those constants in the controller… Okay, of course, but not as good, in my opinion.
I've been developing Symfony apps for more than five years but I'm quite new at hacking internal Symfony code. so, if there is something against Symfony philosophy here, I'd be glad to understand.
Thank you for reading!

\StringBackedEnum does not exist in PHP

Indeed that is an interface only present in PHPStorm stubs but it doesn't change anything :
the principle could still apply to a BackedEum (only int and string are possible as backing values)
And nothing prevents use from having a role named ROLE_1 (allthough that wouldn't make much sense)

enums enable typing only when you target a specific enum. If the parameter type is \BackedEnum to support any backed enum, you loose all typing benefits.

For clarification. I was referencing typing in domain layer not the framework.

That's kind of the issue though. For your domain to use your types consistently, the framework has to support your domain's type somehow. The framework can't support an App\Role enum, it can support BackedEnum or UnitEnum (if you don't want to use backed enums). But even if the framework fully supported enums in the authorization-related code, by the time you get down to your Voter implementation, you still can't rely on your domain types without type assertions or juggling. So even if you could write #[IsGranted(Role::Admin) in your controller, you're still mapping framework types (strings, generic enums) to domain types (App\Role enum) in Voter::supportsAttribute() or Voter::supports().

• IsGranted is declared final for some unknown reason (Ive already made a feature request for this [Security] Make IsGranted Attribute non final to allow usage of custom attributes #60896) which prevents reusing roles and its very common for IsGranted to be used multiple times with same args.

It's always safer to start final and then open something up versus defaulting to a "everything has to be open" policy, especially with a platform as widely used as Symfony. A fair number of attribute classes started final and were then opened through later PRs for very similar reasons.

Voter would only require simple changes to provide a default implementation.

While this is true in theory, it would also force B/C breaking changes on everyone using the CacheableVoterInterface or the abstract Voter class because they'd all have to support more than string attributes. So that is now a very legitimate concern to keep in mind, how does the impact of that change balance out against the convenience of allowing an application's enum types to flow through the authorization-related interfaces.

Making voters generate the cache key does not work: it would require knowing which voter to ask for the cache key before being able to read the cache to know which voter supports that attribute, which is a chicken-and-egg problem.

That's kind of the issue though. For your domain to use your types consistently, the framework has to support your domain's type somehow.

No it doesn't; like, ideally it would, but having easy support for it in the application code is much more important.

I.e. having correct, strict typing for methods like addRole and whatnot is what's the most desirable here (as well as using it in place of strings in attributes and such); the framework having type-checking for them is very much secondary.

One option to make this way more versatile while also allowing implementation flexibility would be to completely ignore Enums, and instead allow a new Interface to be accepted by the annotation, voters, etc. For example, we could have a RoleInterface, that would have a single method returning string (called asRoleName or something similar), and then people could use whatever they want: an enum, a regular class, or literally anything.

@Amunak you can already use whatever representation you want in your own code (strings, enum, a doctrine relation, etc...) for the roles, as long as you handle converting them to the string type expected by symfony/security-core when implementing UserInterface::getRoles

@stof but that still doesn't allow you to also just use the app's implementation for the security attributes and such. This would be a nice way to unify it all, in my opinion.