- What is pragmarx/firewall and what does it actually do?
- pragmarx/firewall is a Laravel package that enforces IP allowlists and blacklists as HTTP middleware. It runs early in the request lifecycle, before routing and authentication, so blocked clients never reach your controllers. Rules come from configuration and a database table, with a cache layer in front to avoid a database query on every request. It also ships Artisan commands for managing the lists.
- How do I install pragmarx/firewall in a Laravel application?
- The mechanical path is composer require pragmarx/firewall, publish the config and migrations, run the migration, register the middleware in your HTTP kernel in the correct position, and seed your allowlist. The real integration cost is not installation but client IP correctness, so configure TrustProxies for your CDN or load balancer topology at the same time. Pin exact versions in composer.json before you deploy.
- Does pragmarx/firewall support Laravel 10, 11 and PHP 8.x?
- Treat this as unverified until you smoke-test it yourself. The package's release history is anchored to the Laravel 5.x era, the repository shows low recent activity, and its dependent count is effectively zero. Middleware signatures, container bindings, facade aliases, and typed properties are all plausible breakage points on Laravel 9, 10, 11 and modern PHP. Pin versions and gate any upgrade behind a PHP and Laravel matrix in CI.
- Can pragmarx/firewall replace a WAF or edge firewall?
- No. It is an application-layer ACL, so every request still terminates in PHP, which means it cannot absorb volumetric traffic. It also cannot protect non-Laravel services in your estate and is blind to layer 7 attack patterns that a real WAF handles. Position it as defense-in-depth behind an edge control, not as a perimeter replacement.
- How do I get the correct client IP behind a CDN or load balancer?
- The middleware is only as accurate as the Request::ip() value it receives, so TrustProxies must be configured to match your CDN or ALB topology. If you get this wrong, the ACL is both bypassable through a spoofed X-Forwarded-For header and prone to false positives against legitimate users. Validate client IP resolution against real production traffic before enabling enforcement.
- Does pragmarx/firewall support blocking by country?
- Country blocking is an optional feature that depends on a GeoIP dataset requiring a licence, periodic refresh, and a lookup dependency at request time. That adds an operational cost that is easy to underestimate. Decide up front whether geo blocking is a compliance requirement or a nice-to-have, and budget for the data licence if it is the former.
- How do I add, remove or clear blocked IP addresses?
- Entries live in a database table and are managed through the package's Artisan commands, which is the recommended path because it keeps the cache consistent. Because lookups are cached, changes made directly in the database may not take effect until the cache is refreshed or expires, which matters during an active incident. Keep the unblock procedure documented and give someone an explicit unblock SLA.
- What is the performance impact of running this middleware on every request?
- The cache in front of the rules exists specifically to avoid one database query per request, so steady-state overhead is low. The risks are elsewhere: cache staleness during an incident, unbounded growth of the block table under attack, and write amplification on your primary database if you auto-block aggressively. Keep blocking administrative rather than adversarial, and push volumetric filtering to the edge.
- How should I test pragmarx/firewall before enforcing it?
- Pilot it on a single low-risk surface such as admin login, running in log-only mode first, and compare logged decisions against real traffic to confirm IP resolution is right. Run Larastan or PHPStan against the package on upgrade to catch signature and typing breakage early. Only enable enforcing mode once you have alerting on block events and a tested rollback path.
- Is pragmarx/firewall still maintained, and what is the exit plan?
- The 23.7 score and thin dependent base should be read as adopt with a fork plan, not adopt as-is. Expect to maintain a fork if you depend on it, and decide early whether durable IP policy belongs at the edge within a defined number of months. A sensible end state is edge enforcement for broad blacklists and geo rules, with this middleware retained only as an auditable allowlist on high-value Laravel route groups.