Nova Aegis Ip Blocker Laravel Package

Product Decisions This Supports

• Build vs. buy on abuse prevention. The package covers IP blocking plus a failed-attempt lock-out rule — table-stakes security plumbing that is easy to underestimate. The decision it informs: do we own this code path (and its edge cases: proxy headers, IPv6, shared NAT, cache flush) or do we consume a maintained implementation?
• Where the "blocked" decision lives. If we adopt this, the application — not just the edge — becomes a place where access is denied. That's an architecture decision with support and observability consequences, not just a library choice.
• Operational safety of lockouts. The v1.2.0 change moves the flag that disables the lock-out rule for the console into an Administrator class. For a PM this is the "don't lock yourself out of artisan, cron, and queue workers" requirement graduating from an ad-hoc exception to an explicit, named responsibility. It belongs in the incident-response runbook and in the acceptance criteria for any rollout.
• Storage and policy as separable concerns. IpBlocker (decision), BlockListWriter (persistence), and Administrator (policy/override) are now distinct. That signals a maintainer investing in structure, and it opens future roadmap options without a rewrite: alternative block-list stores, allowlists, escalation tiers, per-route thresholds, per-tenant lists.
• Roadmap cost of this release: effectively zero. v1.2.0 is explicitly internal-only — no application-facing change, no deprecation, no migration. It consumes no capacity and de-risks later features.
• Use cases worth scoping now: login throttling, admin-panel hardening, API endpoint abuse, public form spam, and per-tenant block lists in multi-tenant products. Scope determines whether the package's model fits or whether we need edge-level blocking instead.

When to Consider This Package

Adopt when:

• You're on a supported Laravel version and want in-application lockout/blocking without adding a WAF vendor or SaaS contract.
• Blocking decisions genuinely need application context — per-user, per-tenant, per-route — that edge rules can't see.
• You want a persistent, inspectable block list rather than a cache-only or in-memory heuristic.
• You need console and background processes exempt from lockout, and you want that exemption to be an explicit, testable behavior rather than a hardcoded carve-out.
• The team is small enough that hand-rolling and maintaining brute-force handling costs more than the integration does.

Look elsewhere when:

• You already terminate abuse at the CDN/WAF. Two sources of truth for "is this IP blocked?" produces inconsistent 403s and support tickets; pick one owner.
• You operate multi-region with strict propagation requirements — DB- or cache-backed middleware will lag behind edge enforcement.
• Data residency or PII constraints make storing raw IPs problematic, and the package offers no hashing/anonymization path.
• You need it to be the only control. It should complement rate limiting, MFA, and credential-stuffing detection, never replace them.
• Maturity risk is unacceptable. At v1.2.0 with thin public assessment data, verify maintainer responsiveness, bus factor, and test coverage before putting this on a public-facing authentication path.

How to Pitch It (Stakeholders)

Executives. We're evaluating a small Laravel package that handles IP blocking and login lock-out so we don't hand-roll security plumbing. The latest release, v1.2.0, is an internal refactor: no application impact, no migration, no new attack surface, no deprecations — zero roadmap cost. The decision it informs is build-versus-buy on abuse prevention; buying here removes ongoing maintenance of a security-critical code path and concentrates that logic in one reviewed place. The real risk isn't the code, it's ownership: if we also block at the CDN, someone must own the authoritative "blocked" decision or we'll generate conflicting responses. Recommendation is to adopt behind a feature flag on one high-value surface, measure lockout false positives for a release cycle, then expand.

Engineering. v1.2.0 is a pure refactor — recovery writes moved from IpBlocker to BlockListWriter, and the console lock-out exemption flag moved into Administrator. Expect no public API change, but the exemption is now a class responsibility: any test or config that silently disabled lockout for CLI needs revisiting. Upgrade is drop-in; run the authentication/lockout suite plus artisan and queue-worker tests that assume they aren't locked out. Treat IpBlocker, BlockListWriter, and Administrator as internals — don't extend them. Review before rollout: block-list writes are transactional, lockout survives a cache flush, forwarded-header/IPv6 handling is correct behind our load balancer, and queue workers are exempt alongside the console.