Whip Laravel Package

Product Decisions This Supports

• Correct client-IP resolution behind proxies, CDNs, and load balancers. WhIP is a small, framework-agnostic PHP library for determining the real client IP when requests arrive through trusted proxies (X-Forwarded-For chains, Cloudflare, AWS ALB, etc.). In a Laravel app it sits underneath every feature that keys off "who is this user" — rate limiting, audit logging, fraud/abuse detection, geo-targeting, A/B bucketing, and analytics attribution.
• Build vs. buy: This is a "buy" (adopt) decision, not a build decision. Proxy-chain parsing looks trivial and is a recurring source of security bugs (spoofed X-Forwarded-For headers, mis-ordered trusted-proxy lists). Adopting a tiny, purpose-built library is cheaper than owning that logic.
• Roadmap input for infrastructure hardening. The v0.5.0 release (PHP 8.0 minimum, CI added, code modernization) is a forcing function to confirm the platform baseline. If any product surface still runs PHP 7.x, this release marks the point where the library stops being upgradeable without a runtime bump.
• Security posture decisions. Whether to trust forwarded headers at all is a product-visible security decision (IP allowlisting, admin panel access, per-IP quotas). The library makes the trusted-proxy list explicit and configurable, which is the safe default versus ad-hoc $_SERVER['REMOTE_ADDR'] reading.
• Not a differentiator. This doesn't create user-facing value on its own; it de-risks features that do. Treat it as infrastructure hygiene, prioritized by whether you sit behind a proxy in production.

When to Consider This Package

Consider adopting when:

• The app runs behind one or more proxies, load balancers, or a CDN, and you need the original client IP rather than the edge IP.
• You need per-IP rate limiting, abuse throttling, audit trails, or geo/fraud logic where a wrong IP is a real correctness or compliance issue.
• Your trusted-proxy topology is non-trivial (multiple hops, mixed trusted/untrusted ranges) or changes between environments.
• You are on PHP 8.0+ — this is now a hard requirement as of v0.5.0.
• You want the trusted-proxy configuration to be explicit and reviewable rather than implied by framework defaults.

Look elsewhere or skip when:

• You are still on PHP 7.x. v0.5.0 drops that support and modernizes the codebase; staying on the older 0.4.x line means no further fixes. Plan the runtime upgrade first.
• Laravel's built-in TrustProxies middleware already covers your needs. For a standard single-CDN or single-LB setup, the framework middleware plus a configured proxy list is sufficient, and adding a dependency buys little. WhIP earns its place when you need finer control, multi-hop logic, or use outside the HTTP kernel.
• You never terminate traffic behind a proxy (direct-to-app deployments), where REMOTE_ADDR is already correct.
• You need a broad networking/geo-IP toolkit — WhIP resolves IPs, it does not do geolocation, ASN lookups, or threat scoring.

Adoption risk to flag: v0.5.0 is a maintenance/modernization release, not a feature release. The changelog shows a single PR: PHP 8.0 floor, CI added, code modernized. That is a breaking change for PHP 7 consumers and a signal that the project is now actively maintained (CI is a genuine quality improvement) but remains a small, low-velocity, single-maintainer-adjacent project. Pin the version, and have a fallback plan since the surface area is small enough to vendor or reimplement if maintenance lapses.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that makes sure we know the real IP address of every visitor. That matters because rate limits, fraud checks, audit logs, and analytics all depend on it — and getting it wrong behind our CDN or load balancer silently undermines those controls. It is not a feature; it is insurance on features we already ship. Cost is negligible; the risk of not having it is mis-attributed traffic and bypassable abuse controls.

To engineering: WhIP handles trusted-proxy and forwarded-header resolution so we stop hand-rolling it. The v0.5.0 release adds CI and modernizes the code, and sets a PHP 8.0 minimum — so confirm our runtime baseline before upgrading, and treat 0.4.x as end-of-line if we can't. Recommended path: pin to 0.5.x, configure the trusted-proxy list explicitly per environment, and add a test asserting the resolved IP for a multi-hop request. If we're on a standard single-proxy setup and already have TrustProxies configured correctly, we can defer adoption — but we should document that decision and the trusted ranges either way.