Symfony Voters

Use when

• A security: expression on an API Platform operation becomes longer than one boolean clause.
• The authorization depends on the object state (owner, published, status).
• Different actions on the same resource need different permission rules.
• You want to test the authorization logic in isolation from controllers / providers.

Default workflow

1. Define the attribute vocabulary (POST_VIEW, POST_EDIT, POST_DELETE, POST_CREATE).
2. Implement a Voter with supports() returning true only for the relevant attribute + subject combination.
3. Implement voteOnAttribute() returning true only when the action is allowed.
4. Wire is_granted('POST_VIEW', $post) in controllers, API operations, or Twig templates.
5. Test each voter in isolation with PHPUnit — permit / deny / abstain.

Guardrails

• Fail closed. If supports() returns false, the voter abstains. If it supports the attribute but the action is not granted, return false.
• One Voter per resource type. Keep the file small and the matrix readable.
• Inject Security, never the request — voters must work outside the HTTP cycle.
• Test every permission matrix entry. Permit, deny, abstain (when applicable).
• No business logic in voters — they read state and decide. Mutations belong elsewhere.

Progressive disclosure

• SKILL.md covers posture and rules.
• reference.md carries the full Voter implementation pattern, integration recipes (API Platform, controller #[IsGranted], Twig), naming conventions, and isolated-testing pattern.

Output contract

• A src/Security/Voter/<Resource>Voter.php file per resource type.
• is_granted('<RESOURCE>_<ACTION>', $subject) used at the integration points.
• A tests/Security/Voter/<Resource>VoterTest.php covering every attribute × scenario combination.

References

• reference.md