Acl Laravel Package

Technical Evaluation

What 2.1.0 actually is: A single-PR minor release ("Soltmar/laravel 13") that appears to add framework-compatibility support for a newer Laravel major. No new features, no API changes, no deprecations signalled in the changelog. Treat this as a maintenance signal, not a capability change.

Package role and architecture fit: laravel-doctrine/acl is a thin adapter that wires Doctrine's ACL/permission-granting subsystem into Laravel's authorization layer (Gate/Gate::allows, @can, policies). It is only architecturally relevant to applications running Doctrine ORM inside Laravel (typically via laravel-doctrine/orm) rather than Eloquent. For an Eloquent-first codebase this package has no fit — Laravel policies plus a permission table cover the same ground with fewer moving parts. Where it does fit, it is a narrow integration seam: entity-level ACL checks delegated to Doctrine, resolved through Laravel's Gate so existing can() call sites keep working. That seam is its main virtue and its main fragility — correctness of authorization now depends on two frameworks agreeing on object identity.

Integration feasibility: Mechanically easy (composer constraint bump), semantically non-trivial. The gating question is the transitive matrix: Laravel major × Doctrine ORM major × PHP floor × the ACL component. Doctrine ORM 3 removed APIs that historically broke ACL-adjacent packages, and a minor release that widens a framework constraint does not by itself prove the ORM combination is exercised in CI. Feasible in a branch in under a day; proving it is safe to ship takes a test pass over every authorization path.

Technical risk: Low for the release itself (minor, additive, no migration). Moderate-to-high for the dependency as a whole: single-maintainer project (TomHAnderson), low commit velocity, narrow install base. The failure mode is asymmetric — a broken ACL either 403s loudly (visible, cheap) or grants too much silently (invisible, expensive). That asymmetry, not the version number, is what should drive scrutiny.

Key questions for the maintainer / our own validation:

1. Does 2.1.0 add the new Laravel major to the support matrix, or replace an older one (i.e., is this an unannounced floor bump)?
2. Was the CI matrix actually extended to run against the new Laravel major and the Doctrine ORM version we pin, or were composer.json constraints merely widened?
3. Any change to illuminate/auth Gate integration or service-provider registration that could alter resolution order against existing Gate::before/after hooks?
4. PHP minimum still unchanged?
5. Is there a documented support window / stated policy for dropping Laravel majors?

Evidence caveat: This evaluation is derived from the 2.1.0 changelog only; no repository, CI, or dependency-graph data was supplied. Items above are validation tasks, not findings.

Integration Approach

Stack fit: Laravel + Doctrine ORM + Doctrine ACL schema. Prerequisites: a configured second (or primary) DBAL connection with the acl_* tables, the ORM service provider, and this package's provider registering the Gate bridge. Incompatible with Eloquent-only applications and with apps that expect per-record row-level tenancy out of the box (ACL object identities are not tenant-scoped by default — this must be layered on).

Migration path: Minor bump. composer require laravel-doctrine/acl:^2.1 in a branch, then resolve. Expect the real friction to be composer why-not output pointing at a pinned Laravel or ORM version, not at this package. If we are already on 2.0.x, the diff should be constraint-only and the upgrade a no-op at runtime.

Compatibility checklist before merge:

• Laravel major supported by 2.1.0 matches our target.
• Doctrine ORM major matches; confirm ACL support for that major is not merely "installs."
• PHP floor satisfied by our runtime images.
• ACL schema migrations present and idempotent against our existing acl_* tables.

Sequencing:

1. Inventory current resolved versions and all call sites touching Gate/can() with Doctrine entities.
2. Branch upgrade; run composer update --with-dependencies for the ACL chain only.
3. Run the authorization test suite; add coverage for any path currently untested (revoked-grant and no-grant cases especially).
4. Verify ACL cache behaviour after grant/revoke (stale-cache regressions don't show in unit tests).
5. Staging with production-like ACL table volume — permission checks are query-bound, and small fixtures hide latency.
6. Roll out behind the existing deploy; no feature flag needed for a constraint-only change, but keep the 2.0.x lock as rollback.

Operational Impact

Maintenance: Minimal footprint, infrequent releases, one effective maintainer. Budget for the possibility of upstream stagnation: pin the minor, subscribe to releases, and periodically re-verify the Laravel/ORM matrix ourselves rather than assuming a release implies coverage. Because authorization is security-relevant, treat this dependency as "reviewed quarterly" rather than "set and forget."

Support: Community-only, no vendor. The realistic mitigation is an exit ramp: because ACL checks surface through Laravel's Gate, the blast radius of replacing this package is contained to the provider registration and the permission-resolution internals. A DB-backed permission table plus policies is a credible fallback and should be documented as such before it's needed.

Scaling: Doctrine ACL is DB-backed and normalized (acl_classes, acl_object_identities, acl_entries, acl_security_identities). Cost grows with object-identity cardinality and graph depth, not user count — deep hierarchies and bulk grant/revoke are the expensive operations, not steady-state isGranted calls. Mitigate with ACL caching (Doctrine supports it) and by keeping object identities coarse rather than per-row. Invalidation on grant/revoke is the trade-off to design deliberately.

Failure modes to instrument:

• Provider not bound to the intended entity manager → checks evaluate against the wrong metadata or deny-all.
• Stale ACL cache after permission change → users retain access they shouldn't; silent.
• Over-permissive mask/bitmask configuration → silent privilege escalation.
• Missing/undeployed acl_* migrations on a new environment → runtime exceptions on first authorized request.
• Unscoped object identities in multi-tenant deployments → cross-tenant access. Alert on authorization-denial rate anomalies in both directions; a sudden drop in 403s is as suspicious as a spike.

Ramp-up: Two distinct skill gaps: Doctrine's entity/UnitOfWork model (a real adjustment for Eloquent-fluent engineers) and ACL concepts (security identities, object identities, permission masks, granting strategies). Budget roughly one to two sprints before a mid-level engineer can safely modify authorization code, and require review from whoever owns the ACL schema. Document the mask semantics in-repo — that knowledge is the least discoverable part of the system and the most consequential to get wrong.

Recommendation: 2.1.0 warrants no action beyond routine evaluation if the target Laravel major matters to us. Continue/adopt only if Doctrine ORM is already the persistence layer; otherwise the correct decision is to not introduce it. Answer the support-matrix questions above before treating 2.1.0 as validated for production.