Recaptcha2 Bundle Proxyable Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork: This bundle is a fork of BeelabRecaptcha2Bundle whose only differentiator is proxy-aware outbound HTTP for the Google verification call. That scope is small enough (typically one client/service decoration plus configuration) that the decision it really supports is "do we fork/vendor a 200-line change or write it ourselves in an afternoon?" — not "which vendor do we standardize on?"
• Network-egress architecture: It surfaces a real product constraint — server-side reCAPTCHA verification requires outbound HTTPS to www.google.com/recaptcha/api/siteverify. If your product ships into corporate VPCs, on-prem installs, regulated environments, or regions where egress is forced through an inspecting proxy, proxy support is a requirement, not a nice-to-have. This package is evidence that the requirement exists and is currently unmet in the mainstream Symfony wrapper.
• Feature scoping for anti-abuse / signup hardening: Informs whether you can keep a simple checkbox reCAPTCHA in the roadmap for self-hosted deployments, or whether you must standardize on a verification approach that works behind restricted egress (alternative vendors, server-side scoring, or a pluggable HTTP client).
• Roadmap / maintenance risk decisions: Low stars, zero dependents, an "in progress" description, and a fork of an upstream project tell you this is not a component to put on a long-lived support path. Useful as a reference implementation and a signal to keep the reCAPTCHA integration behind your own interface boundary.
• Ecosystem fit check: It's a Symfony bundle, not a Laravel package. For a Laravel codebase this does not support a feature decision at all — it supports a rejection decision and points you at google/recaptcha wrapped in a Laravel service provider, or an existing Laravel-specific package with an injectable Guzzle client.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony (bundle registration, DI extension, BeelabRecaptcha2Bundle conventions) — this is not usable as-is in Laravel.
• You are already on, or migrating to, BeelabRecaptcha2Bundle, and re-implementing its form type / validator surface would be more work than a fork.
• You have a hard, non-negotiable requirement that the siteverify call traverse an HTTP proxy (fixed egress IP allowlisting, TLS-inspecting corporate proxy, no direct NAT, per-tenant proxy credentials).
• You are willing to vendor or fork the code into your repo, pin a commit, and own it — treat this as a source drop, not a Composer dependency with expectations of support.
• You have reviewed the LGPL-3.0 implications with legal, particularly if you plan to modify and redistribute (dynamic linking via Composer is generally fine; static/link-with-modifications needs a look).

Look elsewhere when:

• The stack is Laravel. Use a Laravel-native package or wrap google/recaptcha with a Guzzle client configured with proxy. Nothing here transfers.
• You don't need a proxy. Use upstream BeelabRecaptcha2Bundle (better maintained, real user base) or google/recaptcha directly.
• You need operational guarantees: security patching, CVE response, an SLA, or a maintainer you can escalate to. Zero stars, zero dependents, a single-fork lineage and an "in progress" README is a supply-chain risk on an anti-abuse security control — the exact place you don't want unmaintained code.
• You need reCAPTCHA Enterprise, v3 score thresholds, or action/domain validation beyond a simple checkbox-and-verify flow; the wrapper's abstraction is thin and you'll outgrow it.
• You want proxy support without a fork. The cleaner path in most modern Symfony apps is to inject an HttpClientInterface/Guzzle client preconfigured with proxy options into any verifier — that capability is already available without adopting this bundle.
• You can't accept LGPL-3.0 in your dependency policy.

How to Pitch It (Stakeholders)

To executives (one paragraph): A small open-source add-on lets Symfony applications send Google reCAPTCHA verification traffic through a corporate proxy — a real blocker for customers deploying behind restricted network egress. However, it is a near-zero-adoption fork (0 stars, 0 dependents, explicitly "in progress") of an existing bundle, so I do not recommend it as a strategic dependency. Recommendation: treat it as a reference implementation, budget a small engineering effort (days, not weeks) to build equivalent proxy support in-house behind our own interface, and avoid taking an unmaintained third-party dependency on a security-relevant code path.

To engineering (bullets):

• Scope is narrow: a proxy-configured HTTP client for the siteverify POST plus Symfony DI wiring. Our own implementation is likely comparable effort to integrating, reviewing, and vendoring theirs.
• Do not consume via floating Composer constraint. If we adopt at all, pin a commit, vendor the source, and add it to our patch-watch list.
• Wrap reCAPTCHA verification behind our own CaptchaVerifier interface now — that keeps proxy config, vendor choice, and future migration to Enterprise/v3 purely a configuration concern.
• Confirm proxy credential handling (no secrets in committed YAML; use env/secret store) and add timeout/retry/fallback behavior — a proxy outage must not hard-fail signup.
• License: LGPL-3.0 — confirm obligations before any redistribution to customers.

Ask: Approve a ~3–5 day spike to (a) implement proxy-aware verification in-house behind an interface, and (b) close this out as "evaluated, not adopted," so we're not carrying an unmaintained fork in our supply chain.