Filament Loginguard Laravel Package

Product Decisions This Supports

• Session/device security as a shippable feature, not a backlog epic. This release hardens the "This isn't me" flow so device revocation actually kills the underlying Laravel session rows, not just the device↔session mapping. That closes a real account-takeover path — a stolen session previously survived a user revoking the device. For a PM this is the difference between shipping a credible "signed-in devices" screen and shipping one that looks right but doesn't protect anyone.
• Roadmap prioritization for account security. Supports decisions on whether to invest in first-party session management (device lists, remote sign-out, trusted-device memory) versus deferring to password resets and generic "log out everywhere" buttons. The package already supplies the user-facing surface and the enforcement primitives.
• Build vs. buy for a small but non-trivial surface. Implementing correct revocation (atomic transaction around session deletion, identity/trust state, trusted_at clearing, reuse of the existing sign-out path) is easy to get subtly wrong. Buying means inheriting these corrections rather than rediscovering them via incident.
• Trust & safety / support workflows. The 403 guard at the service boundary against revoking the device tied to the current session prevents a user from locking themselves out mid-flow — a class of support tickets and a UX dead end worth designing around.
• Compliance and audit conversations. Device-level revocation with real session termination is a concrete control to cite in security questionnaires (customer-facing SOC 2 / ISO style reviews) and in DSAR-adjacent "terminate access on request" requests.
• Upgrade decision: low-cost, high-value. Patch-level upgrade, composer update only, no schema changes and no migration. There is no migration risk to schedule, no data backfill, and no window where old and new writes conflict — this can ride a normal release train.

When to Consider This Package

Adopt when:

• You run Filament and need a user-facing "My Devices" / active sessions view without building it from scratch.
• Your threat model includes stolen session cookies or shared/borrowed devices — i.e. you need revocation that truly ends authentication, not just cosmetics.
• You want trusted-device memory (trusted_at semantics) so returning users skip repeated 2FA, with the ability to clear that trust on demand.
• You want a pre-built, now-hardened "This isn't me" flow, including the self-lockout guard.

Look elsewhere or build in-house when:

• You are not on Filament — the UI layer is the package's value; a non-Filament stack loses most of it.
• You need session storage abstraction beyond Laravel's session driver (e.g. a bespoke token/session model), or you're an SPA/API-first product where session rows aren't the unit of revocation.
• You require enterprise-grade session intelligence — impossible-travel detection, per-session anomaly scoring, admin-side global revocation consoles. This is a focused package, not a CIAM platform.
• You are on a pre-1.0 dependency policy: 0.7.x signals API churn is still plausible; if you can't absorb minor-version breakage, budget for that or wait for 1.0.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated LoginGuard, a Filament package that gives users a "My Devices" screen with remote sign-out and a "This isn't me" button. The newly released v0.7.1 fixes a genuine security defect: revoking a device previously left the live session authenticated, so a compromised session could outlive the user's revocation. It now deletes the real session rows, wrapped in a transaction, and refuses to let a user revoke the device they're currently on. The upgrade is a composer update with no migrations and no schema changes, and it materially strengthens a claim we make to customers about account control.

For engineering: Patch release, solution-forest/filament-loginguard v0.7.1, no schema changes, no migration. Fixes session-revocation completeness in the "This isn't me" flow: revocation now deletes the device's Laravel session rows inside a transaction alongside identity/trust changes, reuses the existing sign-out path, clears trusted_at, and returns 403 at the service boundary when the target device is the current session. Two things to verify on our side: (1) our own wrappers/tests around revocation assert on the new 403 behavior, and (2) any custom code that assumed revocation was non-transactional or that relied on sessions persisting post-revocation. Recommend upgrading on the next train rather than batching with feature work — the defect is an authenticated-session-persistence bug, not a cosmetic one.