Filament Loginguard Laravel Package

Technical Evaluation

Architecture fit. solution-forest/filament-loginguard is a Filament panel plugin that layers a device/session registry, trusted-device tracking (trusted_at), and self-service revocation ("My Devices" → "This isn't me") onto Laravel's native auth. It is a cross-cutting authentication concern rather than a UI convenience, so it should be classified as a security-critical dependency in our inventory, not as a panel add-on.

Integration feasibility. Very low friction. v0.7.1 is a composer update with no schema changes and no migration. No config or panel-provider changes are implied by the notes.

Technical risk.

• The defect being fixed is a false-assurance bug, not a cosmetic one. Prior to 0.7.1, revocation removed device↔session mappings but left the underlying Laravel session rows authenticated. Any revocation performed on a build < 0.7.1 should be treated as not having happened. This is the dominant risk and it is retrospective, not forward-looking.
• Pre-1.0 versioning. At 0.7.x there is no semver guarantee; minor bumps can change service signatures or behavior. Dependency must be pinned to an exact version with deliberate review per bump.
• Atomicity assumption. The fix wraps session deletion plus identity/trust changes in a transaction. That is only genuinely atomic if the session store writes through the same database connection as the trust changes. A Redis/file/array session driver, or a separate connection, undermines the guarantee and could silently reintroduce partial revocation.
• Behavior change at the service boundary. Revoking the device mapped to the current session now returns 403. Anything that programmatically calls the revocation service — admin impersonation, support consoles, self-service flows triggered from the same session — may begin failing.

Key questions.

1. Which session driver do our target applications use, and does the package's row deletion work against it (or does it no-op)?
2. Is there a device_id/session index supporting the deletion query at our session-table scale?
3. Is there a CVE or vendor advisory for the pre-0.7.1 behavior, and what is the disclosure timeline?
4. Who are all callers of the revocation service, and do any legitimately revoke the current session (and therefore now need to handle 403)?
5. Does the reused sign-out path fire the same logout/session-invalidation events our audit logging depends on?
6. Are stale mapping rows from previously "revoked" devices still present in our data, and do we have a remediation script?

Integration Approach

Stack fit. Laravel with Filament panel(s), PHP 8.1+, database session driver strongly preferred so that "delete session rows" is a real operation. Applications on Redis or file sessions need explicit validation before we claim the fix is effective.

Migration path. Pin solution-forest/filament-loginguard to 0.7.1 exactly (not a caret range), run composer update solution-forest/filament-loginguard, commit the lock file. No migration, no schema change, so deploy is reversible by version pin alone — but the security remediation below is not reversible and is the real migration work.

Compatibility. Confirm the package's Filament major-version constraint against our panels, and audit for local overrides of the sign-out flow or of the revocation service — since the fix reuses the existing sign-out path, any subclass or override we maintain must be re-verified. Verify our logout listeners still fire.

Sequencing.

1. Inventory every caller of the revocation/trust services across web, admin, and support tooling; flag any that revoke the current session.
2. Confirm session driver and add/verify an index on the device↔session mapping before enabling at scale.
3. Stage 0.7.1 in non-production and exercise "This isn't me" end-to-end with real database sessions, asserting the session row is actually gone and the old session cookie no longer authenticates.
4. Deploy the pinned update.
5. Post-deploy remediation (do not skip): identify all devices revoked under pre-0.7.1 versions, re-revoke them under 0.7.1, and force re-authentication for the affected users. Backfill or purge stale mapping rows left behind by the old code.
6. Add explicit handling for the new 403 in support/admin surfaces so it renders as a meaningful message rather than a generic error page.

Operational Impact

Maintenance. Small-vendor, pre-1.0 package with a security-relevant blast radius. We need a standing process: watch releases and advisories, pin versions, and treat every bump as a security review rather than a routine chore.

Support. Two predictable ticket classes follow this release. First, a wave of "I was signed out unexpectedly" from users whose devices were previously (ineffectively) revoked — this is the fix working. Second, support staff encountering 403 when attempting to revoke a device tied to their own session. Both need runbook entries and user-facing copy before deploy, not after.

Scaling. Per-revocation cost is one indexed delete plus a small transaction — negligible. The watch item is session-table growth and the absence of a pruning policy for expired rows and orphaned device mappings, which degrades the deletion query over time.

Failure modes.

• Session store unreachable mid-revocation → transaction rolls back, device appears unrevoked, user believes they are safe.
• Session store on a different connection than the trust tables → partial application despite the transaction, reproducing a milder form of the original bug.
• Non-database session driver → the fix is a no-op and the vulnerability persists silently. This is the highest-severity operational risk.
• 403 from the service boundary surfaced as a generic error, leaving users unable to complete the security action they were attempting.
• Our audit logs showing a successful device revocation under the old version, now contradicted by reality — any compliance reporting built on that data is unreliable.

Ramp-up. Low. Filament-native, no new infrastructure, no migration. The genuine learning curve is conceptual: the device↔session↔trust model and the meaning of trusted_at, which engineers and support both need in order to reason about what revocation now actually guarantees.