Filament Ban Laravel Package

Technical Evaluation

Architecture fit. The package targets a well-understood seam in the Laravel/Filament stack: ban state persisted on the user record (or an adjacent table) plus HTTP middleware that returns a denial before the panel, API, or login flow proceeds. That is idiomatic Laravel — middleware for request gating, a trait for model behavior — and it slots into the Filament panel middleware stack without requiring a plugin service provider or custom page overrides. The conceptual risk is that ban enforcement sits at the intersection of authentication and authorization: if the middleware is positioned as an Authenticate replacement rather than an additive gate, it can silently shadow Filament's own auth middleware or Laravel's auth:sanctum guard. We should confirm the middleware is additive and correctly ordered rather than assuming it.

Integration feasibility. Mechanically straightforward: Composer install, publish config and migrations, apply a trait to the User model, register middleware on the Filament panel (->middleware() and ->authMiddleware()) and on the API route group. Realistic effort is one to three engineering days including test coverage, not a multi-sprint initiative. The uncertainty is not "can we wire it up" but "does its ban semantics match ours."

Technical risk. This is the dominant concern. Ten stars, a single maintainer, and a 0.21 score indicate an unvalidated package with no meaningful community scrutiny. There is no evidence of CI, a release cadence, a security policy, or a documented Filament compatibility matrix — all of which matter for auth-adjacent code. Filament ships majors quickly (v2 → v3 → v4), and auth middleware is exactly the kind of code that breaks quietly across those bumps. The mitigating factor is the MIT license and small surface area: the package is likely a few hundred lines, so forking or internalizing it is cheap. Treat it as reference implementation plus starting code, not as a long-term dependency.

Key questions for the maintainer / code review.

• Is ban state stored as columns on users or in a separate bans table? Does it support temporary suspensions with suspended_until, and are timestamps stored UTC and evaluated consistently?
• Does banning revoke active sessions and API tokens, or does a banned user retain access until their session/token expires? This is the single most important behavioral question.
• Does it hook Laravel's Login/Failed events, or does it subclass Authenticate? How does it interact with Sanctum/Passport and the api guard specifically?
• What happens on a database or cache failure — fail-open (banned users get in) or fail-closed (all users locked out)? Is that configurable?
• Is the ban check memoized per request, or does it issue a query on every middleware pass and every Filament table row?
• Is there an audit trail (who banned whom, when, why) and a notification path to the banned user?

Integration Approach

Stack fit. Assumes Laravel 10/11, PHP 8.1+, Filament v3, and a conventional User model backed by Eloquent. It is a poor fit only if we run multi-guard tenancy with per-tenant user tables, or if ban state must live in an external identity provider — in which case enforcement belongs in the IdP, not in application middleware.

Migration path. Review the published migration before running it rather than trusting migrate blind: confirm nullability, indexes on the suspension timestamp column, and whether a separate bans table is created (better for history, worse for the hot-path join). Adding nullable columns to users is a safe online DDL on MySQL 8 / Postgres for our table sizes. The trait application is a no-op for existing rows since the default state is "not banned." There is no data backfill required.

Compatibility. Pin an exact version in composer.json and record the Filament and Laravel versions it was tested against. Because the package is small, wrap the ban check behind our own BanService or policy interface so that swapping the dependency for in-house code later is a one-file change rather than a refactor. If a Filament v4 upgrade is on the roadmap within twelve months, plan to fork now rather than discovering breakage mid-upgrade.

Sequencing.

1. Spike in a branch: install, publish, read the middleware source end to end, and write characterization tests for the behaviors above.
2. Add to staging with the middleware registered but the enforcement flag off; enable and exercise login, panel access, API token issuance, API calls with an existing token, and token refresh.
3. Explicitly test the ban-while-logged-in case for both session and token auth.
4. Roll to production behind a config flag so it can be disabled in one deploy if it misfires.
5. Only then build the admin-facing surface (ban/unban actions, reason capture, audit listing).

Operational Impact

Maintenance. Budget roughly one to two days per quarter for dependency bumps, or make the internalize-by-default call up front: at this size, vendoring the middleware into our own app/Http/Middleware and owning it is a defensible alternative to tracking an unmaintained package. Either way, name an internal owner — there is no vendor to escalate to.

Support. GitHub issues only, no SLA, no stated security disclosure process. Security review is on us: auth-adjacent code deserves a manual read, and we should watch the repo (or our fork) for advisories. The attack surface is small, but a flaw here is a privilege-escalation class bug, which raises the review bar above what the star count would otherwise justify.

Scaling. The dominant cost is a per-request ban lookup. For a Filament admin panel at low QPS this is irrelevant; for an API at meaningful volume it is one extra query per request unless the check is memoized on the user instance or served from a cache/store. Verify there is no N+1 when Filament renders user listings, and confirm the check does not fire on unauthenticated routes where it cannot resolve a user.

Failure modes to design for explicitly.

• Fail-open vs fail-closed on DB/cache unavailability — decide deliberately; the safe default for a security control is fail-closed with a documented blast radius, or fail-open with alerting if availability dominates.
• Stale sessions and tokens — if the package does not revoke them, a banned user keeps access until natural expiry. Pair it with session invalidation and token revocation ourselves; do not assume the package handles it.
• Timezone/clock skew on suspended_until — store UTC, evaluate UTC, and test the boundary.
• Middleware misordering — a route group that omits the middleware silently bypasses the ban. Enforce via a shared route group and a test that asserts 403 for a banned user on every relevant entry point.
• Cache invalidation on ban/unban if ban state is cached.

Ramp-up. Low for the happy path — a mid-level Laravel developer understands the package in under an hour. The learning cost is entirely in the edge cases: session revocation, token lifecycle, and the chosen failure mode. Those should be documented as a short runbook alongside the rollout, because they are the parts a future on-call engineer will need at 2 a.m. and the parts the upstream README almost certainly does not cover.