Filament User Sessions Laravel Package

Product Decisions This Supports

• Build vs. buy for admin "session management" (buy, at a small scale). The core job — list active sessions, show IP/device/last activity, force-logout, bulk revoke — is the kind of table-stakes admin feature teams re-implement on every project. This package collapses it to composer require plus one ->plugin() call, so the decision is really "spend a sprint building an internal page we'll maintain forever" vs. "adopt ~one page + one widget."
• Security posture / roadmap sequencing. Force-logout gives you a credible incident-response lever ("we see a session we don't recognize, kill it now") without standing up a full SIEM or IdP-driven revocation flow. That unblocks shipping "basic account-security controls" for a customer or auditor while deferring the bigger investment.
• Support-ops capability. The "who's logged in from where" view and bulk stale-session cleanup are genuinely useful for support triage ("user says they're locked out / seeing a weird device") and for a first-line compromised-account playbook.
• New-device signal as a product, not a security, feature. The session_known_devices table plus the ⚠️ flag and opt-in NewDeviceLogin notification is a cheap "did something change for this user?" signal. It informs decisions like: do we invest in real device fingerprinting? Is anomalous-login alerting worth building? Use it to gather signal before committing roadmap.
• Scoping the permission model early. v2.2.0 added policy support (viewAny/view/delete/deleteAny), which means "who is allowed to kick out a superadmin" becomes an explicit product decision rather than a default. Good forcing function: you can decide that a support role may view sessions but only revoke non-admin users, and encode it without forking.
• Framework-upgrade planning. Filament v4/v5 support (v3 still available via the ^1.0 line) means this is not a blocker when you plan a Filament major-version upgrade — relevant input to "when do we upgrade the admin panel."
• Not a decision it supports: anything requiring hard auth guarantees — IdP-level revocation, device attestation, per-session step-up auth, or audit-grade log retention. Don't let a stakeholder conclude that installing this closes an account-security finding.

When to Consider This Package

Consider it when all of these hold:

• You run Filament v4 or v5 and already have an admin panel. Non-Filament or Livewire-only admin surfaces get zero value here.
• Your app uses SESSION_DRIVER=database. This is a hard gate — file, cookie, redis, or array drivers mean the plugin has nothing to read. Verify this before the evaluation, not during rollout.
• You want the capability now and at low cost: a small, MIT-licensed, single-purpose plugin is a reasonable trade for the maintenance you avoid.
• You're willing to own the authorization decision. The default policy is fully permissive: anyone who can reach the panel can view all sessions and revoke anyone but themselves. You must register your own SessionPolicy in your AuthServiceProvider if that's too broad — and it usually is.
• You can accept a coarse new-device signal. The docs are explicit that fingerprinting is browser + platform only, deliberately not IP-based, so two different physical machines on the same browser/OS are indistinguishable. If your threat model needs real device identity, this is not it.
• You have an acceptable dependency-risk appetite: 5 stars, 0 dependents, last release 2026-07-18. That is early-stage, effectively unproven in the wild with a single-maintainer bus factor.

Look elsewhere (or build) when:

• SESSION_DRIVER is not database, or you're planning to move to Redis-backed sessions — the plugin's entire data source would disappear mid-flight.
• You need identity-provider-driven revocation (Okta/Azure AD/Keycloak sign-out-everywhere), which belongs in the IdP or an SSO integration, not a session table.
• You need compliance-grade audit trails — immutable logs, retention policies, export, who-revoked-whom-and-when. This package shows current state, not history.
• Your multi-tenant or multi-panel setup requires tenant-scoped visibility (a tenant admin seeing only their users' sessions). Nothing in the README suggests tenancy awareness; assume you'd be patching it.
• Authorization must be safe by default. If you can't guarantee a policy gets registered before launch, the permissive default is a real risk in a panel reachable by non-superadmins; a hardened in-house implementation may be the lower-risk path.
• Your org has a minimum-maturity bar for dependencies (maintainer responsiveness SLAs, security-disclosure process, version-support policy). This repo shows README and releases but nothing here demonstrates those.

How to Pitch It (Stakeholders)

For executives (one line): A small, free, MIT-licensed plugin that gives our Filament admin panel a "see everyone logged in and kick them out" screen — the basic account-security control customers and auditors ask about — in days instead of a sprint, with no vendor contract.

For engineering leadership:

• Scope: one Sessions page (user, IP, parsed device/browser, last activity), an "Online now" stat widget, single and bulk revoke, and an opt-in "new device" flag plus NewDeviceLogin notification.
• Cost of adoption: composer require, one plugin registration in the panel provider, session:table + migrate (the migration also creates session_known_devices), and optional config publishing. Realistically an afternoon including policy work.
• Hard prerequisite: SESSION_DRIVER=database. Confirm this first; it is the single biggest disqualifier.
• Security caveats we must state plainly and not paper over:
  • Default authorization is permissive — any panel user can revoke any session but their own. We will register our own SessionPolicy. This is a launch blocker, not a nice-to-have.
  • New-device detection is a coarse heuristic, explicitly not a security boundary. It's a UI hint and an alerting trigger, not a control. We should not represent it to customers as device verification.
  • Notifications are no-ops until we implement ResolvesNewDeviceRecipients and point config at it. Budget that work; otherwise the feature silently does nothing.
• Risk to accept consciously: 5 GitHub stars, 0 dependents, single maintainer, recent releases. This is early-stage software. Mitigations: pin the version, fork it if it goes quiet (MIT permits it, and the surface area is one page plus a small model layer), and keep our policy and recipient implementations in our own codebase so a swap-out is cheap. Do not let it become load-bearing for security guarantees.
• What it is not: not an SSO revocation mechanism, not an audit log, not audit-grade retention, not multi-tenant aware. If the requirement is any of those, this is a partial answer and we should say so before it gets into a compliance narrative.

Recommendation: pilot it behind a superadmin-only policy in one panel, verify the session driver and notification wiring in staging, and treat it as a UX-and-ops convenience layer — never as the control that satisfies an account-security audit.