Livewire Access Laravel Package

Getting Started

archtechx/livewire-access is ArchTech's small, pre-1.0 helper for authorizing Livewire components and component actions. v0.1.3 is a maintenance release with one substantive change: Laravel 10 support added, Laravel 8 support removed. Nothing else in the public surface changed.

composer require archtechx/livewire-access:^0.1.3

1. Check your Laravel version first. If the app is still on Laravel 8, Composer will silently resolve you to v0.1.2 (or fail outright if you pin ^0.1.3). Run composer why-not archtechx/livewire-access 0.1.3 before assuming the upgrade worked.
2. Read the README at the exact tag you install. At 0.1.x the API is not stabilised, and the README on main may already describe behaviour that doesn't exist in your locked version. Pin the tag in your bookmarks.
3. First use case: take one existing component that currently has an ad-hoc abort_unless(auth()->user()->isAdmin(), 403) in mount() and replace it with the package's authorization call. That gives you a feel for the ergonomics without a risky refactor.

The realistic day-one value is consistency: one place to express "who may run this component / this action", instead of scattered abort_if calls and Blade @can guards that drift apart.

Implementation Patterns

Component-level gate. Put the check in mount() for whole-component protection — tables, dashboards, detail pages. This is the pattern to reach for first because it's cheap and obvious in review.

Action-level gate. Livewire's model is that every public method is callable from the browser. Any method that mutates state (delete(), approve(), impersonate()) needs its own check, regardless of what mount() did. Treat mount() as a UX guard and per-action checks as the actual security boundary.

Base component / trait. Apply the package's trait to an abstract App\Livewire\ProtectedComponent and have your components extend it. This is where a 0.1.x dependency earns its keep: the churn of a pre-1.0 package is contained to one file when the API shifts.

Policy-backed checks. Map components to Eloquent models and delegate to policies rather than inlining role strings. It keeps the component thin and makes the rules testable outside Livewire.

Blade + server parity. If you hide a button with @can, mirror the same rule server-side in the action. Any divergence here is the most common source of "the button was hidden but the request still worked" findings in audits.

Testing workflow. Livewire's testing helpers don't bypass your authorization — good. Write one test per protected action asserting a 403 (or the package's denial behaviour) for an unauthorised user, using actingAs(). These tests survive package upgrades and are the fastest way to detect a behaviour change after a composer update.

Upgrade pattern for this release. Bump Laravel to 9/10 first, then the package. Doing both at once makes a failing test ambiguous.

Gotchas and Tips

• A patch release dropped a framework version. v0.1.3 removes Laravel 8 in a 0.1.x bump. That is legal for a pre-1.0 package but is a strong signal to pin exactly ("archtechx/livewire-access": "0.1.3") rather than floating ^0.1, and to read the changelog on every update.
• Laravel 8 shops are frozen. You can stay on v0.1.2 indefinitely, but you will receive no fixes. Treat the Laravel 9/10 upgrade as a hard dependency of staying on this package rather than an optional chore.
• Verify the constraint actually moved. After upgrading, composer show archtechx/livewire-access — if it still reads 0.1.2, your root composer.json or a transitive constraint is holding it back.
• mount() runs once; actions run every time. A component authorised on first render can be re-entered via subsequent Livewire requests. Public properties are also settable from the payload — never trust a $this->user set from the frontend for an authorization decision; resolve the user server-side.
• Child components are separate components. Nesting a protected component inside an unprotected parent does not protect the child's endpoints. Each one needs its own check.
• Denials surface oddly. A 403 thrown inside a Livewire action renders through Livewire's error handling rather than a plain HTTP error page; assert on the exception/status in tests, not on rendered HTML.
• Watch for stale caches. After bumping the package, php artisan optimize:clear — config and compiled-view caches obscure behaviour changes during debugging, and it's the first thing to rule out.
• Extension point to lean on: keep your authorization rules in policies/gates that the component calls into. That way, if the package's API shifts in 0.2, you rewrite the glue in your base component and leave the rule definitions untouched.
• Known unknown: at 0.1.x there is no documented backwards-compatibility promise. Budget a small amount of time per update to read the diff; the GitHub compare link in the release notes is the cheapest possible safeguard.