Weave Code
Laravel Ip Gateway Laravel Package
vcian/laravel-ip-gateway
Laravel IP Gateway adds middleware and configuration for restricting access by IP address. Easily allow or deny requests, protect routes, and manage whitelists or blacklists with a simple Laravel-friendly setup.
Laravel IP Gateway
Frequently asked questions about Laravel Ip Gateway
- How do I install vcian/laravel-ip-gateway in a Laravel application?
- Install it with Composer using composer require vcian/laravel-ip-gateway, then publish any config or migration files the service provider exposes and register the middleware (or its alias) in your HTTP kernel or bootstrap/app.php. Apply the middleware to individual routes or route groups depending on which surfaces you want gated. Before you start, check the declared Laravel and PHP constraints in the package composer.json, because the only release is dated 2024-08-23 and may not officially cover Laravel 11 or 12.
- Does Laravel IP Gateway support CIDR ranges and IPv6 addresses?
- The package is described as IP allow/deny gating with CIDR matching, but IPv4 and IPv6 parity is not documented in the overview and must be verified in the source. Write tests that cover exact boundary addresses at the start and end of each CIDR block, plus addresses one octet or one bit outside it. Also test IPv4-mapped IPv6 addresses such as ::ffff:192.0.2.1, since these are a common source of silent bypasses in IP filtering code.
- Is it safe to use X-Forwarded-For headers with this package behind a load balancer?
- Client IP resolution is the critical correctness question for any IP gate, and if the middleware reads X-Forwarded-For without a strict trusted-proxy configuration the allowlist is trivially spoofable. Configure Laravel's TrustProxies middleware with your exact proxy IPs or CIDR ranges and confirm the package resolves the client address from the normalized request rather than the raw header. Review the source to see whether it relies on $request->ip() (which honors trusted proxies) or parses headers itself, and treat that as a release blocker if the behavior is unclear.
- Which Laravel and PHP versions does vcian/laravel-ip-gateway support?
- The package has a single release dated 2024-08-23, so its composer.json constraints are the authoritative answer and should be checked against each target service before adoption. It likely overlaps Laravel 9 and 10 and PHP 8.1 or 8.2, but official Laravel 11 and 12 plus PHP 8.3 support is not guaranteed. Run the test suite and a manual smoke test on your actual framework version rather than assuming forward compatibility.
- Where are the IP rules stored, in a config file or a database table?
- The overview does not specify whether rules are config-driven, database-backed, or cached, so confirm this from the source before designing around it. For most teams config-in-git is the better default: rules are reviewable, diffable, and deploy with the application. Move to database-backed rules only if self-service rule management or a genuine audit trail of who changed what is a real requirement, and remember that a database table duplicates the source of truth already held by your edge WAF or ingress allowlist.
- How do I restrict access to /admin, /horizon, or /telescope to specific IP addresses?
- Wrap those route groups with the package middleware and list the office, VPN, or bastion egress ranges in the allowlist. Middleware ordering matters: the gate should run early, before expensive auth and session work, but after trusted-proxy normalization so the resolved client IP is correct. These low-blast-radius internal surfaces are exactly the right first use case, and you can validate the setup in staging before touching customer-facing routes.
- What happens if the rule storage or cache is unavailable: fail-open or fail-closed?
- The failure semantics are not documented in the overview, so you must test them deliberately by making the rule source unreachable in a staging environment. Fail-closed means a storage outage locks everyone out, which is a self-inflicted outage on admin surfaces. Fail-open means the gate silently disappears during an incident, which is a bypass; decide which risk you accept and make the behavior explicit rather than inherited.
- Is vcian/laravel-ip-gateway production-ready and actively maintained?
- At roughly 43 stars, one maintainer, and a single release dated 2024-08-23, it has low adoption signal and no visible release cadence or published security policy. Treat it as an unvetted third-party dependency until you have completed a code review, and consider vendoring or forking it given the small surface area. Wrapping the middleware behind a thin internal interface keeps a fork or replacement to a one-file change.
- Is the package safe to use with Laravel Octane and long-running workers?
- Octane safety depends on whether the middleware or its service provider retains request state in singletons, which would leak one request's resolved IP or decision into another. Review the source for static properties and constructor-injected request objects, and resolve the middleware per request as Laravel expects. Then run the gate under Octane in staging with concurrent requests from different IPs to confirm decisions stay isolated.
- What are the alternatives to using a Laravel package for IP allowlisting?
- For simple static allowlists, roughly thirty lines of custom middleware using $request->ip() and Laravel's TrustProxies plus a config array is often enough and removes a dependency entirely. At the infrastructure layer, WAF rules, ingress or load balancer allowlists, and VPN or Zero Trust access cover the perimeter more reliably than application code. Use a package like this as application-layer defense-in-depth for internal surfaces, not as your primary perimeter control.
Weaver
How can I help you explore Laravel packages today?