- How do I install buzz/laravel-google-captcha in a Laravel app?
- Install it with Composer via composer require buzz/laravel-google-captcha. The service provider is auto-discovered, so no manual registration is needed on modern Laravel versions. Publish the config file with php artisan vendor:publish to get config/captcha.php, then set your NOCAPTCHA_SITEKEY and NOCAPTCHA_SECRET values in the environment. After that you can drop the Blade directive into a form and add the captcha rule to your validation.
- Which Laravel and PHP versions does this captcha package support?
- Support is defined by the constraints in the package's composer.json, so check those against your target matrix before adopting. The package is maintained by a single author with a small dependent base, so support for future Laravel majors is not guaranteed on any published schedule. Pin the constraint in your composer.json and cover the upgrade in your framework bump checklist. If you are running an older or bleeding-edge Laravel release, verify compatibility manually rather than assuming it.
- Does it support reCAPTCHA v2 and v3, including score and action verification?
- Yes, the package is configurable for both v2 and v3 keys, with the version selected in config/captcha.php. For v3 the important question is whether it exposes score threshold and action verification, or only the boolean success flag from Google's siteverify response. Verifying success alone is a meaningful weakening of v3, since any valid token from any action on your site would pass. Inspect the Captcha class and confirm hostname and action checks are actually enforced before relying on v3 in sensitive flows.
- Can I show multiple captchas on the same page with this package?
- Yes, supporting multiple captchas on a single page is one of the package's stated features, which matters for pages that render several forms at once. Each form still needs its own g-recaptcha-response input and its own validation rule entry. If your forms use different keys or actions, verify in the source how per-instance configuration is passed rather than assuming a single global key works everywhere. Test the multi-widget case explicitly, since that is where most captcha integrations break.
- How do I render the reCAPTCHA widget in a Blade template?
- The package ships a Blade directive, so rendering the widget is a one-liner inside your form tag. Place it before your submit button and make sure the form posts normally so the g-recaptcha-response field is included. If you need custom markup or a specific theme, you can render the widget yourself and use the package purely for server-side verification. The directive is ergonomics, not capability, so there is no lock-in if you outgrow it.
- How do I validate the captcha in a FormRequest?
- Add 'g-recaptcha-response' => 'required|captcha' to your FormRequest rules or an inline $request->validate call. The custom captcha rule performs the siteverify call to Google and returns a validation error when verification fails. Error messages are customizable through the published config or your lang files. Because it is a normal validation rule, it composes with your other rules and fails through the usual Laravel error flow.
- Does this package work with Inertia, Vue, or an API-only backend?
- Only partially. In an Inertia or SPA setup you would render the reCAPTCHA widget client-side yourself and use the package solely for server-side verification of the submitted token, which captures roughly half its value. For pure API or mobile clients the same applies: no Blade directive, just the verification endpoint wrapper. That is still a valid use, but the Blade ergonomics you are paying for go unused entirely.
- How do I test forms protected by this captcha in CI?
- Check the source for a built-in fake or bypass first, since a package of this size may not ship one. The practical approach is to fake the outbound HTTP call to Google's siteverify URL with Http::fake and return a canned success or failure payload. Alternatively, swap or mock the Captcha binding in the container so the rule resolves to a stub during tests. Never let your test suite hit Google's real endpoint, since that makes CI flaky and rate-limited.
- What happens if Google's siteverify endpoint is slow, times out, or returns a 5xx error?
- This is the failure mode that matters most, because registration, checkout, and password reset all sit behind this call. You need to know whether the package throws an exception, returns false, or silently passes on a transport error, since a silent pass is an open door and a hard failure blocks legitimate users. Check whether the HTTP timeout is configurable and what the default is before you ship. Decide deliberately whether an outage should fail open or fail closed, and test that behavior explicitly.
- Is buzz/laravel-google-captcha safe to run in production, and what are the alternatives?
- Blast radius is low because the package is a thin, stateless wrapper with no database, migrations, or queues, and removal is roughly an afternoon's work. The supply-chain risk is medium: one maintainer, few indexed dependents, and no commercial backing, so the real danger is a silent version conflict during a framework upgrade rather than a loud break. A credible alternative is inlining the roughly twenty-line Http::post to siteverify behind your own validation rule and a Blade component, which removes the dependency question entirely for about half a day of extra work. Swapping from another captcha package such as anhskohbo/no-captcha is not a drop-in change, since every form and FormRequest rule needs touching.