- Is jakreiter/recaptcha2-bundle-proxyable a Laravel package?
- No. It is a Symfony bundle: it ships a Bundle subclass, a DependencyInjection extension with a Configuration tree, and Symfony form/Twig wiring. Laravel does not process Bundle::build() or Extension::load(), and there is no equivalent to config/bundles.php auto-registration. The only piece you could reuse in Laravel is the verification client buried inside the bundle, not the bundle itself.
- Can I install this package in a Laravel application?
- You can run composer require, but registering the bundle in Laravel does nothing because Laravel's container and kernel lifecycle are different. The practical path is to extract the verifier logic and wrap it in your own service provider and FormRequest rule, or skip the package and hand-roll the siteverify call. Pulling in a Symfony bundle just to get a Guzzle proxy option is usually net-negative for a Laravel app.
- Does this package support Laravel 10 or Laravel 11?
- There is no Laravel version support because this is not a Laravel package. Its compatibility constraints are Symfony framework versions, not Laravel's, and Laravel's package discovery will not register anything from it. If you need a Laravel-native reCAPTCHA integration, use a Laravel package or build a small in-house verifier instead.
- How do I configure the HTTP proxy for reCAPTCHA verification?
- In the Symfony bundle, proxy settings would be supplied through the bundle's configuration tree alongside the site and secret keys. In a Laravel-native build you would instead place the proxy URL in config/services.php or .env and pass it via Http::asForm()->withOptions(['proxy' => $proxy, 'timeout' => 3, 'connect_timeout' => 2])->post(...). Be aware that the secret and client IP traverse the proxy hop, so TLS termination at the proxy is a credential-exposure risk.
- Does the proxy feature in this bundle actually work?
- The proxy capability is explicitly marked as in progress, which means the exact code path you need may be unfinished or a TODO. Since proxy routing to Google is the one differentiated feature, you should read the diff before relying on it. Treat it as unverified until you have tested it yourself in your own egress-restricted environment.
- What is the Laravel equivalent of this Symfony bundle?
- A Laravel-native equivalent is roughly a four-piece build: config entries for site key, secret, verify URL, and proxy; an App\Services\Recaptcha\Verifier that constructor-injects Illuminate\Http\Client\Factory and posts to https://www.google.com/recaptcha/api/siteverify; a ValidRecaptcha rule or RecaptchaRequest; and a Blade component plus a scripts directive. That is about 150 lines and avoids Symfony coupling entirely. The official google/recaptcha client is also a viable PSR-18-based alternative.
- What are the best alternatives to this package for Laravel reCAPTCHA v2?
- Use google/recaptcha with an injected HTTP client, a maintained community Laravel reCAPTCHA package, or a small in-house verifier built on Laravel's Http facade. Also evaluate whether reCAPTCHA v2 is still the right control in 2025 versus Cloudflare Turnstile, hCaptcha, or reCAPTCHA Enterprise, given v2's legacy status and UX friction. In most Laravel apps, the proxy requirement is a one-line HTTP client option rather than a reason to adopt a dependency.
- Is this package safe and maintained enough for production use?
- It has zero stars, zero dependents, a single maintainer fork, and an unfinished headline feature, which is a weak signal for a security control that needs timely fixes. It is also LGPL-3.0, so closed-source use is possible but forking or vendoring creates relinking and source-availability obligations that need legal sign-off. For a registration or login form, the safer choice is a small in-house verifier you control or the official Google client.
- How do I test reCAPTCHA verification without calling Google?
- In Laravel, fake the outbound call with Http::fake() and return a canned siteverify JSON payload for success and failure cases, then assert your rule or request class accepts and rejects tokens accordingly. Keep the verify URL in config so tests can point at a stub endpoint, and unit-test the verifier's typed result object separately from the form integration. Google also publishes documented test keys for front-end widget testing, but never rely on them in production.
- Should reCAPTCHA verification fail open or fail closed when Google times out?
- That is a product decision, not a library one: fail-closed blocks submissions during a Google or proxy outage, which can block revenue on a registration form, while fail-open silently disables your spam control. A common compromise is a short timeout with a degraded flag logged and alerted, plus a secondary control such as a honeypot or rate limit. Decide this before choosing any package, because the bundle does not make that policy choice for you.