Recaptchaproxyable Laravel Package

Technical Evaluation

• Architecture fit: Narrow. This is a plain PHP HTTP client for Google's siteverify endpoint (a derivative of google/recaptcha), not a Laravel package — no service provider, no config publishing, no facade, no container bindings. Laravel integration is manual wiring you own. It is only the right choice if outbound egress to google.com is blocked, inspected, or geo-restricted; otherwise google/recaptcha is strictly better.
• Integration feasibility: Technically trivial (small, self-contained, Composer-autoloadable, BSD-3-Clause, no expected dependency conflicts). Commercially/supply-chain weak: 0 stars, 0 dependents, single maintainer, no evidence of CI or test coverage, and the headline feature — proxy support — is self-described as "in progress." The package name in the registry (jakreiter/recaptchaproxyable) does not match the repository name (jakreiter/recaptcha), which suggests a personal fork rather than a published, versioned artifact.
• Technical risk:
  • Fork drift: patches and API changes from upstream won't flow; a Google-side change to the verification response contract lands on you.
  • The feature is unfinished: the proxy path is exactly the thing you'd adopt it for, and exactly the thing marked incomplete.
  • Transport correctness: unclear whether HTTPS egress is tunneled via CONNECT or only plaintext proxying is supported; proxy auth, TLS interception trust, and timeout semantics are unverified.
  • Security surface: if the proxy URL is runtime-configurable, treat it as an SSRF vector — validate against an allowlist and never accept it from request input.
  • Observability: unknown whether proxy credentials are masked in exceptions/logs.
• Key questions:
  1. Which upstream google/recaptcha tag/commit is this forked from, and how far behind is it?
  2. Does it honor HTTPS_PROXY/NO_PROXY env vars, or only explicit constructor config?
  3. Does it perform CONNECT tunneling for the TLS call, and how does it handle proxy-injected certificates?
  4. Is the response contract (success, score, action, error-codes) unchanged from upstream, so existing validation logic survives?
  5. Is it on Packagist with semver tags, or VCS-only?
  6. Is there a test suite, including a proxy mock?
  7. Who owns it if the maintainer stops?

Integration Approach

• Stack fit: Fine for Laravel 9–12 on PHP 8.x assuming the Composer constraint allows it — verify before committing, since a stale constraint is the most common blocker for low-traffic forks. No framework coupling means no upgrade friction from Laravel itself.
• Migration path: Do not swap it in at call sites. Put verification behind an internal interface (CaptchaVerifier::verify(token, action, ip)) and treat any client library as an implementation detail. That lets you go google/recaptcha → this fork → back, or → your own 40-line Guzzle client, without touching controllers or form requests.
• Compatibility: Confirm the namespace change is the only breaking delta. Check that error codes and the score/action response shape are preserved, otherwise your threshold logic and user-facing error messages silently change behavior. Keep proxy configuration in config/services.php + env, injected once, never scattered through constructors.
• Sequencing:
  1. Spike (1–2 days): branch, install from VCS pinned to a commit SHA, and prove CONNECT tunneling against a local squid/mitmproxy in front of a mock siteverify endpoint.
  2. Mirror: fork or vendor the repo internally; do not depend on a mutable branch.
  3. Abstract: land the internal interface and config before the dependency, so the dependency is replaceable on day one.
  4. Test: contract tests against a stubbed siteverify plus at least one test through a real proxy, including a proxy-returns-HTML-error-page case.
  5. Canary: enable on a single low-risk surface (password reset) before registration/login.
  6. Fallback: keep upstream google/recaptcha installed and switchable by config until the spike is signed off.
• Preferred alternative: rather than adopting the fork wholesale, upstream a small patch (proxy-aware transport) onto a pinned, current google/recaptcha, or write the thin client yourself. You get proxy support without inheriting an unmaintained tree — this is the recommendation unless the spike shows the fork is both complete and current.

Operational Impact

• Maintenance: This becomes your code the moment it ships. Budget ~1–2 days per quarter for upstream review, security patch triage, and PHP/Laravel compatibility bumps. A vendored 40-line patch costs less than owning a full fork.
• Support: No community, no SLA, zero dependents means zero incidental bug discovery — you are the first and only user of every code path. Name an internal owner and an escalation path before adoption.
• Scaling: siteverify is one synchronous outbound call per verification, and the proxy adds a hop and a second failure domain. Expect roughly +20–100 ms per request and proxy connection-pool limits to become the bottleneck during login storms or campaign-driven signup bursts. Set explicit connect/read timeouts, cap concurrency, and add a circuit breaker so the proxy doesn't become a soft DoS on auth.
• Failure modes:
  • Proxy unavailable → verification fails → registration and login fail. Decide fail-open vs fail-closed per surface (fail-closed on registration, consider fail-open plus rate limiting on password reset) and make it an explicit product decision, not a default.
  • Proxy returns 200 with an HTML error page → naive clients treat it as success. Validate the JSON body and the success field, never just the status code.
  • Credential rotation and proxy TLS interception certificate trust are recurring ops chores; document them in the runbook.
  • Fork drift → upstream security fix never arrives; track the upstream changelog manually.
• Ramp-up: Low for a mid-level PHP developer — the API mirrors google/recaptcha and is a few classes. Budget half a day for someone who knows the upstream library, plus 1–2 days for the proxy validation harness and runbook. The real onboarding cost is not the library; it's the abstraction, the fail-mode policy, and the ownership commitment.