Recaptcha Bundle Laravel Package

Technical Evaluation

Package identity mismatch (blocking). The package is a Symfony bundle (EWZRecaptchaBundle), not a Laravel package. It ships a Symfony Bundle class, a DI extension, and Twig form-theme resources wired through Symfony's form component. Laravel has no Bundle/Extension bootstrap, no Symfony DI container bindings for it, and no kernel registration path. It cannot be composer require'd into a Laravel app and used as described. The only realistic integration is an unmanaged port: extract the reCAPTCHA verification service and reimplement the form macro as a Laravel validation rule / Blade component.

Architecture fit. Even in its native Symfony context, the fit is poor for a modern stack. The code targets the Symfony 2.x form and templating conventions of 2014. It provides a form type and a Twig widget — an opinionated, framework-coupled shape rather than a framework-agnostic client. Any value here is a thin HTTP wrapper around Google's verify endpoint, which is ~40 lines to write yourself; the bundle's actual contribution is boilerplate you would not want to carry.

Integration feasibility. Low. Composer constraints from 2014 will not resolve against supported Symfony or PHP versions (the era implies PHP 5.3–5.6 and Symfony ~2.3–2.6). Dependency resolution failure is the expected first outcome. Forcing it in via --ignore-platform-reqs or a composer fork yields code that calls APIs removed years ago. There is no Laravel service provider, no config publishing, no facade — every seam must be hand-built.

Technical risk (critical). The dominant risk is that the underlying product is dead. A 2014 release predates reCAPTCHA v2 (late 2014) and long predates v3 and Enterprise. It almost certainly emits the v1 recaptcha_challenge_field / recaptcha_response_field protocol, which Google discontinued — the verification endpoint it calls no longer returns a usable success signal. In practice this is not "stale but functional"; it is a package that cannot perform its one job. Secondary risks: 3 stars and 0 dependents means zero community validation, zero issue triage, and no security response capacity; MIT license is fine, but the original upstream (excelwebzone/EWZRecaptchaBundle) is the maintained-lineage artifact, and the Newscoop fork adds an additional provenance layer.

Key questions.

• Is the actual requirement "add reCAPTCHA to a Laravel form"? If so, the answer is a maintained v3/Enterprise client or Google's own JS plus a server-side verify call — not this package.
• Are we inheriting a legacy Symfony 2 application where this bundle is already installed? That is the only scenario where this artifact is even relevant, and it is a migration/removal task, not an adoption task.
• What reCAPTCHA version is mandated by security/compliance? v1 is retired; if any policy still references it, that policy is itself out of date.
• What is driving the "opportunity: 9.35" signal? It should not be read as fitness. With 3 stars, 0 dependents, and a decade of dormancy, high "opportunity" most plausibly reflects an unclaimed/abandoned niche, not unmet demand we should serve with this code.

Verdict: Reject as a dependency. Retain only as a reference for how the original authors shaped a Symfony form type, if we are porting to Laravel and want a starting point for a Recaptcha validation rule.

Integration Approach

Stack fit. None for Laravel. Treat the repo as a design reference, not a library. The portable asset is the pattern — a form field that renders a widget and a server-side verifier that POSTs the token to Google and checks success — not the PHP.

Recommended path (Laravel, greenfield). Build a small first-party package: a Recaptcha validation rule, a Blade component for the v3/v2 widget, a config file for site/secret keys sourced from env, and a thin HTTP client wrapping the siteverify endpoint with timeout and error handling. This is a one-to-two-day task, is fully testable with an HTTP fake, and removes all supply-chain exposure. Do not vendor the 2014 code; reimplement the ~40 lines.

Migration path (legacy Symfony 2 app already using it). Sequence as: (1) inventory every form using the bundle's type and Twig block; (2) confirm which reCAPTCHA version is live and whether verification is currently succeeding — expect it is not; (3) stand up v3 or Enterprise keys in parallel; (4) replace the bundle's form type with a local form type and the Twig widget with a template override; (5) swap the verifier service behind the existing service ID so call sites do not change; (6) remove the bundle from composer.json and delete the DI extension registration once no template references remain. The service-ID aliasing step is what makes this a low-risk cutover rather than a big-bang rewrite.

Compatibility. Assume PHP 5.x and Symfony 2.x only. Do not attempt to satisfy it on PHP 8 / Symfony 6+. If a Laravel adapter is genuinely required, the boundary is a single class implementing a verify(string $token, ?string $ip): bool contract, with the framework-specific glue written fresh on each side — never the bundle's own classes.

Sequencing. Do not start with the dependency. Start with a decision on reCAPTCHA version and key provisioning (owned by security/infra, not engineering), then build or port the verifier, then the form integration. The package itself should be closed out in week one as "not applicable," so it does not sit in a backlog consuming evaluation cycles.

Operational Impact

Maintenance. Zero upstream maintenance. Last release 2014-06-26; no commits, no releases, no issue response, no security advisories. If we ship it, we own it forever, including any CVE in its transitive 2014-era dependencies. Carrying an unmaintained bundle in a modern app also trips SCA/SAST gates in most CI policies, which means ongoing exception paperwork on top of the code risk.

Support. No vendor, no community. Three stars and zero dependents means there is effectively no one to escalate to and no corpus of Stack Overflow answers specific to the fork. Internal on-call would be debugging a dead reCAPTCHA protocol with no upstream to compare against.

Scaling. Irrelevant as a bottleneck — CAPTCHA verification is a per-request outbound HTTPS call and the bundle adds no scaling surface. The real operational coupling is to Google's endpoint: latency, quota, and regional reachability of siteverify become our failure domain, and the 2014 code almost certainly has no timeout, no retry, and no circuit-breaker behavior. That is a self-inflicted availability risk on every protected form.

Failure modes. (1) Hard failure — Composer refuses to resolve; caught at install, cheap. (2) Silent failure — bundle installs but v1 verification always returns failure or the retired endpoint errors, so every submission is rejected or, worse, a false is coerced and every submission passes. This is the dangerous one: a broken CAPTCHA that fails open is indistinguishable from no CAPTCHA until abuse occurs. (3) Blast radius is limited to forms using the type, but that typically includes registration, login, and password reset — i.e., the highest-value unauthenticated endpoints. (4) No graceful degradation path exists in the code, so an outage at Google becomes an outage in our signup funnel.

Ramp-up. Near-zero cost to understand (it is a small, conventional Symfony bundle), but high cost to own. An engineer can read it in an afternoon; making it work on a supported runtime is a rewrite, and the honest framing to the team is "we are writing our own, using this as a reference." Budget the effort as greenfield, not as integration, or the estimate will be badly wrong.

Recommendation. Decline adoption. Close the evaluation with a one-line decision record pointing to a maintained reCAPTCHA v3/Enterprise integration (or an in-house ~40-line verifier), and flag the version/keys decision to security as the actual blocking dependency.