-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[Security][TwigBridge] Add access_decision() and access_decision_for_user() #61379
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
base: 7.4
Are you sure you want to change the base?
[Security][TwigBridge] Add access_decision() and access_decision_for_user() #61379
Conversation
…ld (antalaron) This PR was merged into the 7.3 branch. Discussion ---------- [Mailer] [Resend] Add friendly name in the `to` field | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | n/a | License | MIT This PR adds support for friendly email address formatting (e.g. "John Doe <john@example.com>") in the `to` field. Although Resend's API accepts this format natively, the current implementation of the bridge does not pass it through correctly — names are silently discarded and only raw email addresses are used. This fix ensures that display names are preserved and passed to the API as intended. Commits ------- f9c0a3d Add friendly name in the `to` field
This new function returns an AccessDecision object, allowing for further treatment in user land such as collecting the vote reasons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks useful to me
some tests + changelog entries would be needed
if ($attachements = $this->prepareAttachments($email)) { | ||
$payload['attachments'] = $attachements; | ||
if ($attachments = $this->prepareAttachments($email)) { | ||
$payload['attachments'] = $attachments; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like a rebase is needed :)
public function accessDecision(mixed $role, mixed $object = null, ?string $field = null, ?AccessDecision $accessDecision = null): AccessDecision | ||
{ | ||
$accessDecision = $accessDecision ?? new AccessDecision(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not there's a point for templates to pass a previous access decision:
public function accessDecision(mixed $role, mixed $object = null, ?string $field = null, ?AccessDecision $accessDecision = null): AccessDecision | |
{ | |
$accessDecision = $accessDecision ?? new AccessDecision(); | |
public function accessDecision(mixed $role, mixed $object = null, ?string $field = null): AccessDecision | |
{ | |
$accessDecision = new AccessDecision(); |
public function accessDecisionForUser(UserInterface $user, mixed $attribute, mixed $subject = null, ?string $field = null, ?AccessDecision $accessDecision = null): AccessDecision | ||
{ | ||
$accessDecision = $accessDecision ?? new AccessDecision(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function accessDecisionForUser(UserInterface $user, mixed $attribute, mixed $subject = null, ?string $field = null, ?AccessDecision $accessDecision = null): AccessDecision | |
{ | |
$accessDecision = $accessDecision ?? new AccessDecision(); | |
public function accessDecisionForUser(UserInterface $user, mixed $attribute, mixed $subject = null, ?string $field = null): AccessDecision | |
{ | |
$accessDecision = new AccessDecision(); |
public function accessDecision(mixed $attributes, mixed $subject = null, ?AccessDecision $accessDecision = null): AccessDecision | ||
{ | ||
$accessDecision = $accessDecision ?? new AccessDecision(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function accessDecision(mixed $attributes, mixed $subject = null, ?AccessDecision $accessDecision = null): AccessDecision | |
{ | |
$accessDecision = $accessDecision ?? new AccessDecision(); | |
public function accessDecision(mixed $attributes, mixed $subject = null): AccessDecision | |
{ | |
$accessDecision = new AccessDecision(); |
public function accessDecisionForUser(UserInterface $user, mixed $attributes, mixed $subject = null, ?AccessDecision $accessDecision = null): AccessDecision | ||
{ | ||
$accessDecision = $accessDecision ?? new AccessDecision(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function accessDecisionForUser(UserInterface $user, mixed $attributes, mixed $subject = null, ?AccessDecision $accessDecision = null): AccessDecision | |
{ | |
$accessDecision = $accessDecision ?? new AccessDecision(); | |
public function accessDecisionForUser(UserInterface $user, mixed $attributes, mixed $subject = null): AccessDecision | |
{ | |
$accessDecision = new AccessDecision(); |
this is already covered by the AccessDecision::getMessage method |
This PR adds 2 new methods and the corresponding twig helpers to retrieve the access decision from a Voter rather than simply the result. This way, you can enumerate the AccessDecision::votes and retrieve the votes and their reason.
For instance, in a controller or service:
Same for a user on his behalf, and same in Twig;
Given that the main motivation for this is to explain in an API or in twig the reasons why the access is not granted, I'm tempted to pre-filter the failed votes already, or add an extra getter AccessDecision::failedVotes to help create these small extensions ?
Side note: 2 extra commits given that I started in 7.3, will fix if this picks up interest