- How do I install niladam/livewire-ban in a Laravel application?
- Install it with Composer using composer require niladam/livewire-ban, then publish the package config so you can tune ban reasons, durations and cache keys. Register the blocking middleware in your HTTP kernel or route group, and make sure your cache store is shared across app nodes. Because the surface area is small, a spike should take hours rather than sprints.
- Which Laravel and Livewire versions does livewire-ban support?
- The expected target is Laravel 10, 11 or 12 with Livewire 3, but you should confirm the exact constraints in the package composer.json rather than assuming. The project has a single maintainer and low adoption, so verify compatibility with your installed Livewire major before committing. If you run an older Livewire version, check for open issues or be prepared to fork under the MIT license.
- What exactly triggers a ban strike in livewire-ban?
- The package hooks the Livewire request and exception lifecycle and records a strike when an exception occurs that a legitimate browser session could not realistically produce. The premise is a heuristic, not a security boundary, so treat it as noise reduction and defense-in-depth rather than access control. Review the source to see which exception classes and request shapes count before enforcing bans in production.
- Where are strikes and bans stored, and what is the retention policy?
- Strikes and ban state are cache-backed, which is why a shared store such as Redis is a hard prerequisite in multi-node deployments. Ban durations and reasons are configurable, so you decide the TTL and escalation policy. Document the cache key prefix so on-call can purge bans without a deploy, and set a retention decision for stored IP addresses because they are personal data under GDPR.
- Can livewire-ban ban legitimate users behind NAT or a shared VPN?
- Yes, and this is the dominant risk: corporate NAT, carrier-grade NAT, shared VPN egress and CI or headless clients can all share one IP, so banning it becomes a multi-user outage. Use the ready-made Livewire component to review and manually unban, and keep an allowlist for known shared egress and health checks. Run in log-only mode first and compare against access logs before enforcing.
- Is there a log-only or dry-run mode to validate before enforcing bans?
- Roll out as an opt-in feature flag: install, publish the config, and run in log-only mode on a single route group before enforcing globally. Compare the logged candidates against your access logs and error tracker to estimate false positives. Rollback is trivial because the package is additive configuration and middleware, and flushing the ban keyspace clears any state.
- Does livewire-ban work across multiple servers and under Laravel Octane?
- It needs a shared cache store such as Redis so counters and ban keys are consistent across nodes; the file cache driver makes the feature per-node, and the database driver adds write pressure on the path that is already failing. Configure TrustProxies for your actual edge, whether ALB, Cloudflare or Fastly, so Request::ip() returns the client rather than the proxy. Under Octane, verify the package keeps no problematic static state in long-lived workers and test in a non-HTTP context before shipping.
- Will the original Livewire exception still reach my error tracker when a ban fires?
- Banning should not swallow the underlying exception, and the key question to answer in a code read is whether your handler and error tracker still receive it. If auto-bans mask real defects behind a 403, teams stop fixing the actual Livewire bug. Confirm the behavior during your spike and add alerting so ban events are observable alongside exception reports.
- Is livewire-ban a replacement for Laravel throttle or a WAF?
- No. It is a complement: the WAF blocks known-bad signatures, Laravel throttle limits volume, and this package catches anomalous Livewire-specific traffic. IP rotation is trivial for a determined actor, so the realistic win is suppressing scanner and fuzzer noise rather than stopping a targeted attacker. Position it as defense-in-depth and keep the overlap deliberate.
- Who maintains livewire-ban, and is it safe to run in production?
- It is a single-maintainer MIT package with very low adoption and no dependents, so there is no community validation or commercial backing. The MIT license means you can fork, but someone on your team must own that option. Budget one to two days for a code read and a dependency security review, and decide up front whether a cache outage should fail open as v1.1.1 suggests.