Laravel Auth Laravel Package

Technical Evaluation

Architecture fit arcanedev/laravel-auth is a conventional Laravel package: a service provider, a facade, publishable config and migrations, and traits applied to the User model to attach role/permission semantics. That shape fits any Laravel application cleanly and is the strongest argument in its favor. The countervailing point is that authorization is a cross-cutting concern — it is invoked from middleware, controllers, Blade directives, policies, and API resources. A stale authorization layer has a blast radius across the entire request surface, unlike a stale utility package that can be isolated to one call site. It also sits in the ARCANEDEV suite and almost certainly depends on arcanedev/laravel-support, which multiplies the abandoned-dependency footprint rather than containing it.

Integration feasibility Composer installation is trivial; the constraint resolution is not. A package last released 2018-09-06 was built against the Laravel 5.5–5.7 / PHP 7.1–7.2 era. On Laravel 9/10/11 the illuminate/* and PHP version constraints in its composer.json will block installation outright, and --ignore-platform-reqs is not an acceptable production posture — it defers the failure to runtime. Feasible integration therefore requires either a fork with widened constraints and a modernized codebase, or a greenfield Laravel 5.x application, which we are unlikely to start in 2024+.

Technical risk High, and concentrated in three places. First, abandonment: no security patching, no CVE monitoring, no compatibility work with future Laravel majors. Second, zero dependents means zero field validation — no one is exercising this code in production, so edge cases in role inheritance, guard scoping, and cache invalidation are unproven. Third, authorization code fails in two directions: fail-closed produces support tickets and blocked users, fail-open produces a security incident. The score of 0.28 and 26 stars are consistent with a package that was a personal utility project rather than an adopted library. For a security-relevant concern, that is the wrong risk profile.

Key questions

• What are the exact composer.json constraints for PHP, illuminate/support, and arcanedev/laravel-support? Does a compatible laravel-support version even exist for our target Laravel?
• Does the package implement its own ACL tables and checks, or does it wrap Laravel Gates/Policies? If it wraps them, we can lift the semantics and discard the code.
• Is there a super-admin bypass, and is it implicit or explicit? Implicit bypasses are a common audit finding.
• How are permissions cached, and what invalidates the cache on role change?
• Multi-guard support: does it scope roles per guard, or is it global?
• Does the test suite exist, run, and pass on the Laravel version we would target?
• What are the migration assumptions — users table name, ID type (bigint vs UUID), FK cascade behavior?

Integration Approach

Stack fit Fits only a legacy Laravel 5.5–5.7 application that is already on the ARCANEDEV stack and already depends on laravel-support. On any modern Laravel, it does not fit as a dependency; it fits at most as a design reference.

Migration path Three viable paths, in descending order of preference:

1. Reject and use the platform. Laravel Gates and Policies cover the majority of authorization needs natively; spatie/laravel-permission covers the role/permission persistence layer with active maintenance and broad adoption. This is the default recommendation.
2. Mine for semantics. Read the source to extract the role/permission model, resolution order, and caching strategy, then reimplement on top of native Gates. Low cost, no dependency, keeps whatever the team liked about the API.
3. Fork and vendor. Only if there is a specific capability in the package we cannot get elsewhere. Fork to an internal namespace (App\Support\Auth or an internal Composer package), widen the constraints, port to the current Laravel, add tests, and own it permanently.

Compatibility The blocking check is a composer why-not on the target Laravel version, run before any code is written. Secondary checks: PHP 8.x compatibility (removed each(), implicit nullable params, dynamic properties, str_* / array_* behavior changes) and whether the laravel-support dependency can resolve at all. If laravel-support cannot resolve, the fork scope expands to two packages and the calculus shifts decisively toward option 1.

Sequencing Time-box a one-sprint spike behind a feature branch: resolve constraints in a scratch container, run the package's own test suite, wire up one real authorization check behind a feature flag, and write down the diff we had to make to get there. Gate the decision on that diff size — if it is more than a handful of lines, stop. Do not run this in parallel with a broader framework upgrade; conflating the two makes the failure attribution ambiguous.

Operational Impact

Maintenance If adopted, we own it. Budget for a Laravel-major-upgrade tax every 12–18 months plus ad-hoc PHP minor fixes, and assign a named owner. An unowned fork of an abandoned authorization package is a latent outage.

Support There is no upstream support channel, no release cadence, and no security advisory feed. Dependency scanners will flag it (correctly) and we will need a documented, signed-off exception in the risk register. That exception needs a review date attached.

Scaling Role and permission checks execute on nearly every request. Verify that resolution is cached per-user and that the cache is invalidated on role change — an uncached check that issues two or three queries per request is invisible in dev and expensive at production request volume. Profile with the package in place before trusting it.

Failure modes

• Permission cache not invalidated on role change → stale access grants, silent and hard to reproduce.
• Fail-open default in a resolver edge case → unauthorized access, security incident.
• Fail-closed on a null/unknown role → user lockout, support ticket spike.
• Composer constraint lock → blocks the next framework upgrade, delaying the whole platform roadmap.
• Autoload collision if forked under a new namespace but the original is still transitively required via laravel-support.

Ramp-up Learning the API is a day. Learning to trust it is a week of source reading by someone senior enough to judge authorization semantics. Size the estimate accordingly — the cost is not adoption, it is verification, and verification is the part that cannot be skipped for security-adjacent code.