Logical Authorization Bundle Laravel Package

Technical Evaluation

The framing problem comes first. Despite the brief describing a "Laravel/PHP package," this is a Symfony bundle (symfony-logical-authorization-bundle), built for Symfony 4. A Symfony bundle is not a portable PHP library: it ships a *Bundle class, DI extension, compiler passes, and service definitions consumed by Symfony's kernel and bundle registration. Laravel has no mechanism to load it. So the honest technical evaluation is not "how well does it integrate" but "is there anything here worth extracting, and at what cost."

Architecture fit. As shipped: poor-to-none for a Laravel codebase. Bundles are tightly coupled to Symfony's container, event dispatcher, security token storage, and routing. There is no realistic path to composer require this into a Laravel app and have it work. The concept, however, is a genuine fit for a known Laravel gap: Laravel's Gate/Policy model covers ability checks and instance-level authorization but gives you little out of the box for (a) composable logical expressions over permissions (A and (B or not C)), (b) field/attribute-level permissions, and (c) uniform enforcement across model, field, and route layers. That gap is presumably what the 1.85 opportunity score reflects. The opportunity is real; this repository is not the vehicle.

Integration feasibility. Three viable paths, in descending order of effort:

1. Adopt nothing; build natively on Gate/Policy + middleware. Lowest risk, highest build cost, best long-term fit.
2. Extract the evaluation engine. Verify whether the bundle delegates to a framework-agnostic core (e.g., an ordermind/logical-authorization-style library). If so, the engine may be salvageable as a standalone Composer package wrapped in a Laravel service provider, a Gate::before/Gate::after bridge, and route middleware. If the expression parser and permission resolver live inside the bundle, extraction means rewriting the Symfony-coupled parts — realistically a multi-week fork, not an integration.
3. Fork the bundle wholesale. Only defensible if part of the estate is Symfony 4; contradicts the stated brief.

Technical risk. High, concentrated in three areas. Abandonment: 23 stars, 0 dependents, composite score 0.645 — no downstream projects means no de facto compatibility testing, no bug reports, no fork ecosystem. Assume the maintainer is inactive and you own all future patches. Platform decay: Symfony 4 reached end of life in November 2023; PHP version support and PHP 8.2/8.3 compatibility are unverified. Security-critical surface: authorization code that fails open is a privilege-escalation incident, and this code has no external scrutiny to lean on. MIT license is the one clean dimension — forking and relicensing internally is unencumbered.

Key questions to resolve before any commitment.

• Is the evaluation engine a separate, framework-agnostic package, or is it entombed in the bundle? This single answer swings the effort estimate by an order of magnitude.
• What is the actual transitive dependency surface — symfony/security-core, symfony/http-kernel, Doctrine, expression-language? Each one is a porting liability.
• Does the expression evaluator use Symfony's ExpressionLanguage (portable, well-maintained) or a bespoke parser (portable only if cleanly decoupled)?
• Does it run on PHP 8.2+/8.3 and Laravel 10/11, or has it never been tested there?
• What is the original motivation — do we need composable logical permissions, field-level permissions, or both? Requirements should drive the decision, not the artifact.

Integration Approach

Stack fit. The mismatch is structural, not cosmetic:

Nothing in the left column maps cleanly to the right without an adapter layer you write and own.

Migration path. If we proceed, treat it as a port, sequenced as: fork to an internal namespace → strip the bundle shell (Bundle class, DI extension, compiler passes, config tree) → isolate and unit-test the pure evaluation logic against fixture permission sets → publish as an internal Composer package → build a thin Laravel adapter (service provider, Gate bridge, route middleware, optional Eloquent scope for row-level filtering) → backfill tests to Laravel's testing conventions. The fork must be vendored or mirrored in private Packagist, not depended on from the public repo, so an upstream deletion cannot break builds.

Compatibility gates. Pin the PHP floor explicitly; verify against the project's PHP version before any design work. Confirm PSR-4 autoloading and absence of Symfony-only type hints in the code you keep. If the retained code pulls symfony/expression-language, that is acceptable — it is framework-neutral and actively maintained — but the bundle's security-core coupling is not.

Sequencing, with exit criteria.

1. Spike (≈1 week): read the source, answer the key questions, prove the evaluator can run standalone. Exit: yes/no on extraction.
2. Requirements confirmation: enumerate the authorization decisions we actually need (which models, which fields, which routes, how many roles). Exit: written permission matrix; if it fits Laravel policies plus one middleware, stop here and build natively.
3. Engine extraction + test suite. Exit: 90%+ coverage on expression evaluation, including fail-closed behavior on malformed expressions.
4. Laravel adapter + one pilot resource behind a feature flag. Exit: shadow-mode comparison against existing authorization for two weeks; zero discrepancies.
5. Incremental rollout resource by resource, with the old path retained until each is signed off.

If step 1 fails, the fallback is the native build — and that fallback should be the default expectation, not the contingency.

Operational Impact

Maintenance. This becomes a permanent internal fork. Budget ongoing ownership: security patching on an abandoned dependency, PHP/Laravel upgrade compatibility on every major bump, and stewardship of an authorization library that every engineer will touch and few will understand. Authorization code has an unusually high blast radius per line changed; this is not a component you can leave unowned.

Support. There is no vendor, no active maintainer, no CVE feed, and — critically — zero dependents, meaning no community has stress-tested this in production. Support is entirely internal, and the bus factor is whoever did the extraction. Mitigate with documentation and at least two engineers through the port.

Scaling. Two distinct concerns. Evaluation cost: expression parsing and permission resolution per check can be expensive at request scale; compile/cache resolved permissions per user-and-role and invalidate on role change — do not parse per check. Data scale: field-level checks applied after fetching rows do not reduce query load and risk leaking rows you fetched but meant to hide. Model-level permissions must translate into query scoping (global scopes or query builders), or row-level authorization becomes an N+1 and a correctness hazard. Decide this at design time; retrofitting query-level enforcement is a rewrite.

Failure modes to design against explicitly.

• Fail-open on parse errors or missing permission definitions — must be fail-closed, with loud logging.
• Route coverage gaps: a new endpoint that forgets the middleware silently bypasses authorization. Enforce coverage with a route-inventory test.
• Cache staleness: stale permission caches granting revoked access.
• Expression ambiguity: precedence, negation, and inheritance interacting in ways reviewers cannot reason about; require canonical test fixtures per permission.
• Silent denial in production that looks like a bug rather than a policy decision; emit structured authorization decisions for audit.
• Fork drift: divergence from upstream makes any future upstream fix unmergeable — accept this upfront.

Ramp-up. Expect 2–4 weeks before a mid-level engineer can safely modify permission logic, driven by two costs: the package's thin documentation (23 stars implies a small user base and correspondingly few answered questions), and the conceptual overhead of logical permission composition. Weigh that against Laravel's Gate/Policy, which every Laravel hire already knows. A custom authorization DSL is a lasting tax on onboarding.

Bottom line. Low stars, zero dependents, an EOL framework target, and a hard framework mismatch put this firmly in "reference design, not dependency" territory. The underlying idea — composable, layered model/field/route authorization — is worth pursuing; this package is best read as a specification for what to build, with a one-week spike to determine whether the evaluator can be lifted. Commit to the fork only if the spike proves clean extraction, and default to building natively on Laravel's Gate until it does.