hello@Spomky 👋🏻

a bit unrelated to PR review, but still worth mentioning imho (feel free to hide the comment later)

as you mentioned "and an optional reason"

wdyt of cascading close perhaps all those PRs and issues (#58107 et al.originally from this) and ask ppl that may subscribe to those PR to come here reviews?

One thing I think should be added here is a way to specify the user we're wanting to check authorization for like was added in#48142 as we won't always have a user session while dealing with authorization (console commands, messenger messages, etc)

hello@Spomky 👋🏻

a bit unrelated to PR review, but still worth mentioning imho (feel free to hide the comment later)

as you mentioned "and an optional reason"

wdyt of cascading close perhaps all those PRs and issues (#58107 et al.originally from this) and ask ppl that may subscribe to those PR to come here reviews?

Hello@94noni,

I love the idea. I will ping contributors of the other PRs/Issues to be part of this PR too.

One thing I think should be added here is a way to specify the user we're wanting to check authorization for like was added in#48142 as we won't always have a user session while dealing with authorization (console commands, messenger messages, etc)

Helli@natewiebe13,

I changed to Role(Hierarchy)Voter to handle that.

$accessDecision =$accessControlManager->decide(newAccessRequest('ROLE_xxx',// The security attribute$subject// Can be null (current user, similar to what the attribute AccessPolicy('ROLE_xxx') does), a security token or a user object));

@Spomky not exactly what I mean. For example, I may want to see if a specific user has publish access to a blog post. In that instance, the subject would be the blog post and the attribute would be something likePUBLISH. So we'd need another way to pass the user.

@Spomky not exactly what I mean. For example, I may want to see if a specific user has publish access to a blog post. In that instance, the subject would be the blog post and the attribute would be something likePUBLISH. So we'd need another way to pass the user.

Sorry, I answered a bit quickly.
I think it is possible with the metadata property that is designed for passing extra information to the voters.
In this case the call will be something as follows:

$accessDecision =$accessControlManager->decide(newAccessRequest('PUBLISH',// The security attribute$post,// The subject    ['target' =>$user]// Arbitrary key here. Change 'target' with another key name. Shall be the same as the one used by the voter (btw use constant instead of hardcoded string)));

The voter:

<?phpnamespaceAcme\Voter;finalreadonlyclass PublishBlogPostVoterimplements VoterInterface{publicfunctionvote(AccessRequest$accessRequest):VoterOutcome    {$target =$accessRequest->metadata['target'] ??null;//Check the target is valid. Throw an exception when required, return VoterOutcome::abstain('...') or use the current user depending on your application needs;//Check if the user is granted or not and return VoterOutcome::deny('...') or VoterOutcome::grant('...');    }publicfunctionsupportsAttribute(mixed$attribute):bool    {return$attribute ==='PUBLISH';// Just for the example    }publicfunctionsupportsSubject(mixed$subject):bool    {return$subjectinstanceof BlogPost;// Just for the example    }}

@Spomky I had a feeling that's what might be suggested. I'd argue that async is becoming more and more common, and at least for the projects I work on happen often enough, that there should be a more concrete mechanism, rather than arbitrary array keys. I'd personally prefer it if you had to explicitly set the target, then the component doesn't have to even consider sessions or assume that the target user is going to be set somehow. But that's likely a bit too extreme for some. Either way, I still like the idea of this component, just hope we get a more concrete way of specifying the target.

@Spomky I had a feeling that's what might be suggested. I'd argue that async is becoming more and more common, and at least for the projects I work on happen often enough, that there should be a more concrete mechanism, rather than arbitrary array keys. I'd personally prefer it if you had to explicitly set the target, then the component doesn't have to even consider sessions or assume that the target user is going to be set somehow. But that's likely a bit too extreme for some. Either way, I still like the idea of this component, just hope we get a more concrete way of specifying the target.

I understand your concern, and honestly, I initially added apublic mixed $requester = null to theAccessRequest class. However, I wasn’t entirely sure about this approach because the requester is not necessarily the "target" of the votes. It could be an intermediary, like a service or a proxy making the request on behalf of a different user, or even a system component. This makes the identification of the "target" somewhat ambiguous.

That said, I agree that having a more concrete and explicit way to set the target could simplify the logic and make the component more predictable, especially for common cases like direct user-to-resource access.
Maybe the metadata property could change in a concrete classAccessMetadata with "standard" properties instead of an array.