No Captcha Laravel Package

Technical Evaluation

Release reviewed: 13.0.0 — published with empty release notes. No changelog body, no migration guide, and no dependency/platform data was included with this release. The version number is the only signal available, and a version number is not evidence of what changed. This assessment is updated to reflect the fact of a major bump while explicitly marking every compatibility claim as unverified pending the tag diff and composer.json.

Architecture fit. Unchanged in substance. arcanedev/no-captcha remains a thin Laravel adapter over Google's siteverify endpoint: a service provider, a facade (NoCaptcha), a publishable config file, a captcha validation rule, and Blade helpers. No persistence, no schema, no queue or event coupling, no domain model — it touches only the HTTP client contract and Laravel's validator. Still a clean fit for a server-rendered Laravel monolith validating via FormRequests or $request->validate().

Still a poor fit — and to be scoped out — for API-first, SPA/Inertia, or mobile clients, where the widget is rendered by a JS SDK, the token is POSTed to your own JSON endpoint, and you would call siteverify directly. The Blade layer is where the value lives; a headless target reduces the package to "a Guzzle call plus a config array."

Caveat added by this release: a major version bump is exactly when thin-surface packages tend to change their surface — facade aliases, config keys, the validation rule name, directive names. We should assume the shape described above still holds only after confirming it against 13.0.0.

Integration feasibility. Greenfield effort is still low and low-uncertainty: 0.5–1 developer-day including tests, contingent on the version constraint resolving on our platform. Two new feasibility items, both caused by the release rather than by the package's design:

• The staleness blocker may have lifted — but not visibly. A 13.0.0 under ARCANEDEV's Laravel-tracking convention most plausibly indicates support for a newer Laravel major (the illuminate/support constraint is the thing to check first). If so, the previous "fails composer update on Laravel 10+" finding is stale and must be retired. We cannot assert this without the tag.
• Empty notes on a major version is a blocker of a different kind. Semver major implies breakage by definition. If we already have the package pinned anywhere, we cannot size the upgrade delta from the release notes; we must diff composer.json and the source between our pinned tag and 13.0.0. Budget +0.5–1 developer-day for that diff if an existing pin is in play.

Technical risk. The risk profile has shifted rather than shrunk:

• Maintenance staleness — partially retired, not resolved. Prior finding was "last release 2022-02-10, four years dark." That specific claim is now false. What replaces it is weaker: one major release, no notes, no stated cadence. A single tag does not establish a maintenance regime, a release process, or a deprecation policy. Downgrade this risk from "abandoned" to "unproven activity."
• Undocumented breaking changes — newly elevated. This is the dominant risk now. An empty changelog on a major bump means we cannot distinguish "added Laravel 13 support" from "removed the facade, renamed config keys, changed the validation rule." The second is silent breakage in templates and FormRequests that only surfaces at runtime. Mitigation is procedural, not technical: read the tag diff before adopting, and pin to an exact version.
• Bus factor of one — unchanged. Single maintainer, no announced succession, no vendor, no SLA, no security response process.
• Zero dependents — recheck. This was a double signal (no downstream pressure, no evidence of broad hardening). It may have changed with the release; verify against Packagist before relying on the prior figure.
• Blast radius still contained — and this remains the decisive mitigator. siteverify is a simple, stable API and the wrapper is a few hundred lines. Forking, vendoring, or reimplementing is genuinely cheap. The package is viable as a starting implementation, not a strategic dependency.
• Compliance risk unchanged and organizational. Google reCAPTCHA retains GDPR / Schrems II exposure (CNIL and other DPA decisions), independent of any package version. Still pushes teams toward Cloudflare Turnstile or hCaptcha. Legal/Privacy review stays on the critical path.
• No official Google support — community wrapper, not an SDK, at any version.

Key questions to resolve before commitment:

1. What does 13.0.0 actually change? The release body is empty — read the CHANGELOG, the compare diff from our last-known tag, and the composer.json constraint.
2. What is the resulting supported matrix — Laravel and PHP versions — and does it cover our target platform? One composer why-not settles it.
3. Is the public surface unchanged: facade alias, config keys, captcha rule name, @captcha directive? Any of these breaking is a silent-runtime failure for us.
4. reCAPTCHA v2 only, or v3 with score thresholds? Invisible-mode callback supported? Does the release add Turnstile/hCaptcha adapters, which would change our fallback calculus?
5. Is secret-key handling still env-only, and does it survive php artisan config:cache?
6. Is the failure policy configurable per form — fail-open vs. fail-closed?
7. Who owns the fork if constraints break, and what is the trigger threshold? With an undocumented major now in the history, "any major without a changelog" should be added to that trigger list.
8. Would Privacy/Legal accept a Google dependency, or is Turnstile mandated?

Integration Approach

Stack fit. Unchanged in principle: best value in a Blade-rendered Laravel app on the version line the package supports. What changed is that we no longer know which line that is — 13.0.0 may extend support to a newer Laravel major, which would convert this from a fork-first exercise back into a plain composer require. Do not pre-commit to the fork path until the constraint is verified; equally, do not assume the new major resolves cleanly just because the number went up. And continue to refuse permanent constraint overrides (--ignore-platform-reqs, hand-edited composer.json) as an undocumented steady state.

Migration path. Same shape, with a mandatory first step inserted:

1. Establish the delta. Compare 13.0.0 against our last-known-good tag — composer.json constraints, facade registration, config file keys, validation rule signature, Blade directive output. Produce a one-page internal changelog, because upstream did not.
2. Abstract the boundary. Define CaptchaVerifier::verify(string $token, ?string $ip): Result and register the package as one adapter behind it. ~40 lines that convert stale-package and breaking-change risk into a swappable implementation detail — and that insulate us from the next undocumented major.
3. Keep the package out of domain code. No NoCaptcha:: facade calls in controllers, services, or jobs; only in the adapter and rule registration.
4. Vendor or fork if the delta is unacceptable. Prefer a maintained fork over patching in vendor/. Publishing config and owning the fork in an internal namespace keeps the Blade directive stable for template authors.

Compatibility. Verify against the full matrix, not just our runtime version: PHP 8.x, illuminate/* constraints, config:cache and route:cache interaction, and rule registration under the target Laravel's discovery conventions. Re-test the JS asset path specifically — major versions are a common point for the pinned Google URL to change, which matters if we run a strict CSP (script-src / frame-src allowlisting of google.com and gstatic.com).

Sequencing.

1. Spike (2–3 days, slightly larger than before): install 13.0.0 in a scratch branch on the real Laravel version, confirm resolution, read the delta, and confirm a real token verifies server-side. Kill the option early if the constraint fight is ugly.
2. Privacy review in parallel — Google dependency, data residency, consent implications. Can veto the choice; must not be serialized after engineering.
3. Adapter + tests: contract, one adapter, unit tests against a mocked HTTP client, one recorded-response integration test.
4. Single low-traffic form behind a feature flag, instrumented for verification success/failure/timeout.
5. Progressive rollout once failure rates match baseline. Keep the flag a full release cycle — captcha regressions present as silent submission failures.
6. Fallback decision point: if Turnstile is approved, adding it as a second adapter is a small increment once the boundary exists.

Operational Impact

Maintenance. Revised. The prior "expect near-zero upstream activity" is no longer accurate, but it has not been replaced by a track record. Budget 2–4 hours per quarter for dependency review, and now also require a delta review on every upstream major — the empty 13.0.0 notes mean the changelog cannot be assumed to exist. Add "major release without a changelog" to the fork trigger alongside a Laravel major upgrade, a PHP minor that breaks a constraint, or any security advisory on the HTTP path. The fork remains small enough to own without dedicated headcount; name an owner explicitly.

Support. Community-only — no vendor, no SLA, no disclosure process — at 13.0.0 just as before. Incidents route to our own on-call. Ramp-up for a Laravel-fluent engineer stays around half a day. The knowledge that matters is not the package but the failure policy and the key rotation procedure; document both. Add a third document: our internal changelog from step 1, so the next upgrade has a baseline the release notes did not provide.

Scaling. Unchanged and version-independent. Each submission adds one synchronous outbound HTTPS call to Google, typically 100–300 ms p95 depending on region and connection reuse — a real tail-latency contributor at volume and a throughput dependency on a third party. Keep the call off critical read paths, set explicit Guzzle timeouts (the default "no timeout" is a hazard), and verify quota and billing posture on the Google side; Enterprise tiers differ from free tier.

Failure modes. Same set, with one addition:

• Undocumented breaking change on upgrade (new) — a renamed config key or rule alias fails validation silently or universally, and with no upstream changelog we have no early warning. Detect via the adapter's integration test in CI on the pinned version, and treat any version bump as a code change requiring review.
• Google unreachable / timeout — the most consequential mode. Fail-closed stops every form during a Google incident; fail-open removes bot protection exactly when probing is likely. Decide per form (fail-open for newsletter, fail-closed for account recovery), make it configurable and observable.
• Misconfigured or rotated secret — universal verification failure, indistinguishable from an outage unless logged with the Google error code (invalid-input-secret, timeout-or-duplicate, hostname-mismatch). Log the response code, never the secret.
• Domain/hostname mismatch after a migration or new staging host — silent, environment-specific, a recurring "works locally, fails in prod" ticket.
• Token reuse or expiry — tabs open past the two-minute window produce a confusing failure; needs a retry affordance, not just a validation error.
• CSP or ad-blocker interference — the widget fails to render for a slice of users; a blocked script looks identical to a bot server-side. Monitor client-side render failures separately from server-side verifications.
• Accessibility — the audio challenge is a poor experience; confirm a documented fallback and that Support knows the script.

Overall. The 13.0.0 release materially changes one input — the package is not abandoned as of 2022, and the previously assumed Laravel 9 ceiling may be gone — but it changes it without documentation, which adds an upgrade risk it did not previously carry. The structural judgment holds: low integration cost, contained blast radius, single maintainer, an unresolved Google compliance question. Adopt it as a reasonable accelerator for a Blade-based Laravel app only if we (a) diff the release before pinning, (b) wrap it behind an internal interface, (c) pin to an exact version and document why, and (d) name a fork owner. Treat it as replaceable from day one; do not adopt it as a strategic dependency without a Privacy sign-off on the Google relationship.