Weave Code
Acl Bundle Laravel Package
project-a/acl-bundle
ACL bundle for Project A that adds role- and permission-based access control. Define roles, assign permissions, and protect routes and resources through configuration, with simple checks for authorization throughout your application.
Providing an easy way to work with the Symfony Security Acl.
Frequently asked questions about Acl Bundle
- Does project-a/acl-bundle work with Laravel out of the box?
- No. project-a/acl-bundle is a Symfony bundle wrapping the Symfony Security ACL component, and it has no Laravel service provider, facade, configuration surface, or Eloquent integration. Using it in Laravel is a porting exercise: you would either bootstrap a slice of the Symfony security stack or reimplement its semantics on Laravel Gate and policies.
- How do I install project-a/acl-bundle in a Laravel app?
- There is no supported Laravel installation path. The package is installed through Composer for Symfony applications, but in a Laravel app there is no ACL provider, security token storage, or MutableAclProvider in the container to make it function. Expect Composer resolution problems on modern PHP and Doctrine/Symfony constraints rather than a working Laravel integration.
- Is project-a/acl-bundle compatible with PHP 8?
- There is no evidence of PHP 8 support. The underlying symfony/security-acl package is abandoned, and the v1.1.0 release does not address PHP 8, modern Doctrine, or the component's removal from supported Symfony versions. Composer resolution failure is the expected outcome on PHP 8.x with current constraints.
- Which Laravel versions does project-a/acl-bundle support?
- None officially. The package does not target Laravel and provides no Laravel version constraints, service provider, facade, or framework integration. Any Laravel compatibility would be custom work maintained outside the package.
- How do I protect Laravel routes and resources with project-a/acl-bundle?
- You cannot protect Laravel routes or resources with this bundle directly because it does not provide Laravel middleware, Gate integration, or container bindings. In Symfony it works through ACL checks around configured roles, permissions, object identities, and security identities. In Laravel you would need to build that hosting layer yourself or map the concepts to Gate abilities and policies.
- Is project-a/acl-bundle maintained and safe for production?
- Maintenance is sporadic and single-maintainer over an abandoned foundation. v1.1.0 shows an active but very low-cadence maintainer, which is better than fully archived, but there is no release cadence, published support window, security advisory process, or evidence of a second maintainer. For production, treat it as a risk to contain in a legacy Symfony context, not a strategic authorization dependency.
- What changed in project-a/acl-bundle v1.1.0?
- v1.1.0 fixes a class permission evaluation bug and adds conveniences for supplying ObjectIdentity instances and class names directly instead of having the bundle construct them. All three changes are Symfony-domain changes. The release does not add Laravel integration, PHP 8 support, modern Doctrine support, or a resolution for the abandoned symfony/security-acl foundation.
- Why does Composer fail to install project-a/acl-bundle on PHP 8?
- Composer resolution failure is expected because the package depends on an abandoned Symfony ACL foundation and does not target PHP 8 with modern Doctrine/Symfony constraints. Constraint aliasing can force an install, but it produces a permanently unsupportable branch. That is not a safe basis for a new Laravel or production authorization implementation.
- What are alternatives to project-a/acl-bundle for Laravel authorization?
- For Laravel, use Laravel's built-in Gate and policy system or a maintained Laravel authorization package that integrates with the framework. If the real requirement is a legacy Symfony 2.x or 3.x application already using this bundle, the alternative is containment and an exit plan rather than adopting the ACL model in Laravel. The ACL object-identity and security-identity matrix brings performance and correctness pitfalls that are best avoided without an active community.
- How do I migrate from project-a/acl-bundle ACLs to Laravel Gate and policies?
- First inventory the existing roles, permissions, object identities, and inheritance or masking rules, then map them to Laravel abilities, policies, and model checks. Testing needs to cover permission evaluation, batch preloading behavior, inheritance, and denial cases because the ACL model has known correctness pitfalls. Migration is a reimplementation of authorization semantics, not a package swap, so audit each protected route and resource before cutover.
Weaver
How can I help you explore Laravel packages today?