Filament Scanner Guard Laravel Package

Product Decisions This Supports

• Protecting Filament admin panels from automated abuse. The package appears to sit in front of (or alongside) Filament and track/ban requests from scanners, bots, and other suspicious traffic — informing decisions on whether to ship an in-house middleware vs. depend on this.
• Operational visibility for security response. The bans-per-day chart (and the 1.2.0 fix preserving that history after purge/unban) is a dashboard signal — it supports product/ops decisions around monitoring trends, spotting attack spikes, and justifying further investment in hardening.
• Data retention & admin workflows. Purge/unban functionality implies an admin-facing control surface; decisions about retention policy, false-positive handling, and analyst workflow depend on how reliable this history is (now improved in 1.2.0).
• Build vs. buy for "scanner blocking in Filament." A small, actively maintained, Filament-native package nudges toward buy/adopt rather than building custom rate-limiting + ban logic.
• Feature/roadmap input. 1.2.0 mostly hardens CI and fixes a dashboard data-integrity bug — a signal that the package is in maintenance/stabilization mode, not rapidly adding capabilities, which matters for roadmap planning if you rely on it.

When to Consider This Package

Consider adoption when:

• You run a Filament-based admin/back-office and want a low-effort layer to detect and ban scanner/bot traffic.
• You want visibility (bans-per-day chart) into malicious traffic without building custom dashboards.
• You need admin controls (purge/unban) and can accept the package's opinion on data retention.
• You value Filament-native integration over a generic WAF/middleware solution.
• Your threat model is largely opportunistic scanners rather than determined attackers.

Look elsewhere when:

• You need enterprise-grade WAF/edge protection (Cloudflare, AWS WAF, Fail2ban at the reverse proxy) — this is a Filament plugin, not an infrastructure-grade solution.
• You require strict SLA/security commitments, formal security review, or long-term vendor support.
• Your application is not Filament-based, or you cannot tolerate an additional package/middleware hop on admin routes.
• You need fine-grained, multi-tenant, or IP-reputation-based blocking logic that this package doesn't expose.
• You're sensitive to dependency/maintenance risk — 1.2.0 is largely CI and dependency housekeeping, so verify the maintainer's responsiveness and release cadence against your risk bar.

How to Pitch It (Stakeholders)

For executives: This is a small, Filament-native security package that watches for scanner/bot traffic against our admin panel and blocks repeat offenders, with a built-in dashboard showing bans over time. Version 1.2.0 is a stabilization release: it fixes a data-integrity issue so ban history survives purge/unban actions, and it standardizes the test/CI pipeline (a sign of maintenance rigor, not new features). It's a cheap, low-risk addition if we already run Filament — not a substitute for edge/WAF protection.

For engineering: The plugin provides scanner detection, ban enforcement, and an admin UI with a bans-per-day chart and purge/unban actions. 1.2.0 fixes the chart losing history after purge/unban (worth re-testing your dashboard expectations), bumps dependencies, and standardizes the tests workflow for the 1.x line (with testbench now supporting ^10 || ^11). Adopt if you're on Filament and want a turnkey middleware/plugin layer; pair with reverse-proxy or WAF-level protection for anything beyond opportunistic scanning. Watch maintenance cadence — this release is housekeeping-heavy rather than feature-rich.