Sessions Devices Livewire Laravel Package

Getting Started

Install and confirm what you actually got. The package is a presentation adapter, so expect it to depend on a core sessions/devices module rather than owning the domain logic itself:

composer require liberusoftware/sessions-devices-livewire

Before writing any code, read composer.json in the installed vendor directory and check three things:

1. The require block — you almost certainly need the core liberusoftware/sessions-devices package (and a supported Livewire major). If the core package isn't pulled in automatically, install it explicitly.
2. extra.laravel.providers — confirms whether the service provider is auto-discovered or must be registered in bootstrap/providers.php.
3. The license field — the registry reports NOASSERTION, so confirm the actual license text in the repo before shipping it into a client project. With 0 stars and 0 dependents, treat this as unvetted code and pin an exact version in composer.json ("liberusoftware/sessions-devices-livewire": "1.0.0", not ^1.0).

Where to look first, in order:

• src/ — find the Livewire component classes (typically src/Http/Livewire/ or src/Livewire/). The class names tell you the component aliases and their public properties.
• resources/views/livewire/ — the Blade views you'll be publishing/overriding. These reveal what the component expects (a collection of sessions, a device model, a user binding, etc.).
• config/ — publish it if present:

  php artisan vendor:publish --provider="Liberu\SessionsDevices\Livewire\SessionsDevicesLivewireServiceProvider"
  

  Use --tag= if the provider defines tags; run php artisan vendor:publish with no args to list available tags.
• database/migrations/ — you need a sessions table (Laravel's default database session driver migration) or a dedicated devices table. Check whether the package ships its own or expects Laravel's.

First use case: a "Security" tab on the user profile page. This is the canonical job — list the user's active sessions/devices, mark the current one, and offer "Log out other browsers." Wire it into an authenticated route:

{{-- resources/views/profile/security.blade.php --}}
<livewire:sessions-devices />

If the component requires parameters (a user, a guard), the class's mount() signature and the view's @livewire(...) calls in the package's own tests are the fastest source of truth. Read the package's test suite if one exists — it's usually more accurate documentation than the README.

Validate the release date claim. The registry lists a release dated 2026-10-26, which is either a mis-parsed tag or a pre-dated release. Run composer show liberusoftware/sessions-devices-livewire --all and confirm the tag resolves to a real commit before you build a dependency on it.

Implementation Patterns

Drop-in on the profile page (the 80% case). Mount the component inside an auth-protected route and let it render its own list. This keeps the security UI decoupled from your profile controller:

Route::middleware(['auth', 'password.confirm'])->group(function () {
    Route::get('/profile/security', SecurityPage::class)->name('profile.security');
});

Wrapping the route in password.confirm is worth doing — the component's revoke actions are destructive and the package is unlikely to enforce re-authentication itself.

Embedding vs. full-page components. Livewire 3 uses <livewire:alias />; Livewire 2 uses @livewire('alias'). Confirm which major the adapter targets — a mismatch here produces a silent blank render rather than a clear error. If the class is namespaced and not aliased, you can always instantiate it explicitly:

<livewire:liberu.sessions-devices.sessions-index />

Handle the "revoked current session" event. The important integration detail is what happens when a user logs out their own current session. Either the component excludes it, or it dispatches an event after revocation. Grep the source for dispatch(, emit(, or $this->redirect and hook in:

#[On('session-revoked')]
public function handleRevocation(): void
{
    if ($this->wasCurrentSession()) {
        Auth::logout();
        session()->invalidate();
        session()->regenerateToken();
        $this->redirect(route('login'));
    }
}

Assume nothing here — verify by testing revocation of the current session manually.

Override views rather than forking. Publish the views and edit them in resources/views/vendor/{package-namespace}/. This is the supported extension point and survives composer update. Keep the published views in version control and diff them after upgrades.

Subclass components for app-specific behavior. If you need extra columns (IP geolocation, last-activity formatting), extend the package component and re-register it under the same alias, or register a new alias:

Livewire::component('sessions-devices', MySessionsIndex::class);

Do this in a service provider that boots after the package provider.

Multi-guard setups. If your app has web and admin guards, check whether the component resolves the user via auth()->user() or an explicit guard property. If it's hardcoded to the default guard, you'll need to swap it or bind a user resolver. This is the most common source of "wrong user's sessions shown" in adapter packages.

Testing. Use Livewire's test helpers and actingAs to assert the rendered session list and the revoke action:

Livewire::actingAs($user)
    ->test(SessionsIndex::class)
    ->assertSee('Chrome')
    ->call('revoke', $sessionId)
    ->assertDispatched('session-revoked');

Note that session-backed tests need the database driver to be meaningful; array sessions in the test environment usually produce empty lists.

Style integration. The shipped views are almost certainly Tailwind (or plain Bootstrap). Rather than fighting them, publish and strip the classes to match your design system, or wrap the component and scope your own CSS. Don't try to override via !important from a parent — Livewire's DOM diffing makes that fragile.

Gotchas and Tips

Session driver is the #1 pitfall. You cannot enumerate sessions from the file or cookie driver in any reliable way. The listing view will be empty or wrong unless you're on the database (or redis with a known key convention) driver. Check config/session.php and be prepared to migrate to the database driver, run php artisan session:table, and migrate — this is a prerequisite, not an optional step.

Vendor risk is real. Zero stars, zero dependents, a NOASSERTION license, and a release date that looks wrong. Pin the exact version, read src/ end-to-end before production use (it's likely a few hundred lines), and be prepared to vendor it into your own namespace. Budget time for that; don't assume upstream fixes.

Livewire version mismatch fails silently. The package was published/updated recently but may target Livewire 2 idioms (@livewire, $emit) while you're on Livewire 3. Symptoms: component renders nothing, or events never fire. Verify by checking composer.json requires and grepping for emit( vs dispatch(.

Config cache after publishing. If you publish a config file and change it, run php artisan config:clear (or config:cache in deploy). A stale cached config pointing at the wrong session table produces confusing "no sessions" results.

Current-session identification. The component must compare session()->getId() against the stored session ID. If your app regenerates the session ID on login (Laravel does by default), ensure the identification still works. Test by logging in fresh and checking the "this device" badge appears on exactly one row.

Don't let revocation log you out of the current device. Verify explicitly that "log out all other devices" preserves the current session. If it doesn't, guard the action with a check before dispatch. This is the kind of edge case an unmaintained adapter is likely to miss.

Migrations aren't always shipped. If the package provides no migrations, you need Laravel's own sessions table — php artisan make:session-table (or session:table on older versions) plus a migrate. Missing migrations surface as a SQLSTATE[42S02] Base table or view not found: sessions at render time.

Debugging approach. Livewire errors during render() often surface as an unhelpful 500 with an empty response. Bisect by calling the component class directly in Tinker (app(SessionsIndex::class)), then check storage/logs/laravel.log. The browser network tab's /livewire/update response payload usually contains the real exception when the UI shows nothing.

Extension points to know. The three reliable ones are (a) published Blade views, (b) subclassing the component and re-registering the alias, and (c) container bindings for any repository/resolver interface the package type-hints. If none of those cover your need, fork into app/ rather than patching vendor/.

Publish-then-update overwrites. Published views are not overwritten by vendor:publish unless you pass --force, which is good — but it also means published views silently drift from upstream. Re-publish to a temp directory and diff on every upgrade.