Laravel Altcha Laravel Package

Technical Evaluation

Architecture fit. laravel-altcha is a thin Laravel adapter over altcha-org/altcha: server-side verification of proof-of-work payloads, a validation rule, a Blade component, and a publishable config file. It occupies the CAPTCHA slot in the form pipeline. The default path is stateless — no migrations, no queue, no daemon — so it slots into horizontally scaled, containerized, multi-node deployments without shared state. That statelessness is the main architectural draw versus traditional CAPTCHA services (which add a third-party network hop and a privacy/compliance conversation).

Integration feasibility. High. Composer install, publish config, add the rule to existing FormRequests, drop the widget into Blade. Existing $errors handling works unchanged. The real work is front-end: the solved token must be injected into the payload before submit. Plain Blade forms are trivial; Livewire/Inertia/SPA forms require manual token plumbing and are where the estimate grows.

Technical risk.

• Major dependency delivered in a minor release. 2.3.0 is a patch-level semver bump that pulls altcha-org/altcha v2 (a major). Risk is low if we only touch the Laravel-facing surface; it becomes a de facto breaking change if any of our code or an intermediate package called the vendor library's challenge/verify API directly.
• Replay window. Without single-use enforcement, a solved payload can be replayed within its expiry window. The headline feature addresses this, but it is opt-in — default behavior is unchanged, and unchanged behavior is the risk.
• Single-use reintroducies shared state. Enforcement implies server-side persistence of consumed solution signatures, which drags back the cache/DB dependency that made this attractive in the first place, plus a cache-eviction correctness problem.
• Not a bot classifier. Proof-of-work raises cost per request; it does not stop a funded or targeted attacker, and it is actively unhelpful on high-frequency API endpoints.
• Supply chain. Single-maintainer community package; the headline feature arrives from a first-time contributor. Small audit surface, low bus factor.

Key questions.

1. Does 2.3.0 change config keys, the validation rule signature, or published views? Is there an upgrade note for anyone using the vendor library's API through this package?
2. What is the exact storage contract for single-use solutions (cache driver, DB table, TTL alignment with challenge expiry), and on store unavailability does it fail open or closed?
3. Is the JS widget vendored/pinned or fetched from a CDN at runtime? If CDN — what's the CSP (script-src, worker-src) and availability story?
4. Which forms actually warrant this? Scope it before building.
5. Does the package's test matrix cover our PHP/Laravel versions, and is the single-use path tested?

Integration Approach

Stack fit. Blade + FormRequest applications: drop-in. Livewire/Inertia/SPA: workable, but treat token capture as a small integration project. No Octane or Horizon concerns beyond cache-driver choice. Multi-tenant safe because default mode is stateless.

Migration path. There is no prior assessment, so scope this as a net-new dependency, not an upgrade. Pin ^2.3 for the package and pin altcha-org/altcha explicitly in composer.json so a future minor release cannot silently drag in another vendor major. Avoid wildcard constraints.

Compatibility. Verify declared PHP/Laravel support against our runtime before the spike. Check the published config filename and Blade component namespace for collisions. Confirm CSP permits the widget script and the Web Worker it spawns — worker-src omissions are the most common silent failure with this class of library.

Sequencing.

1. Spike, 1–2 days: branch, disposable form, verify both submit and reject paths end-to-end.
2. Decide on single-use before rollout, not after. Retrofitting a storage path under a live form is more disruptive than designing it in.
3. If enabling single-use: confirm the cache driver is shared across all nodes and that TTL ≥ challenge expiry.
4. Roll out to one public unauthenticated form. Prioritize registration and password reset over contact forms.
5. Instrument first: log verification failures with reason; track solve time and abandonment.
6. Expand or roll back on 2–4 weeks of conversion and abuse data.

Do not put this in front of authenticated high-frequency API traffic; the cost/benefit inverts there.

Operational Impact

Maintenance. Low baseline cadence — mostly dependency-bump PRs and rare feature drops — but this release shows the pattern: a vendor major arriving inside a package minor. We own the pin and the upgrade testing. Treat any release touching the altcha-org/altcha constraint as a full verification test pass regardless of semver.

Support. No vendor SLA. Escalation path for a production break is "fork and patch." Confirm we can read and modify a few hundred lines of PHP and that the license permits it.

Scaling. Server-side verification is CPU-cheap (hash comparison) and scales linearly when stateless. Single-use enforcement converts every verification into a cache/DB read-write, inheriting that store's scaling and availability profile. Negligible on Redis; an extra write per submission plus a cleanup job on a database table. Size accordingly.

Failure modes (roughly by likelihood):

• Widget blocked or fails to load (CDN, CSP, ad-blocker heuristics) → form becomes unsubmittable for a subset of users, often silently. Highest-likelihood production incident; needs a visible fallback.
• Cache store unavailable with single-use on → verification fails closed and every submission errors. Decide the policy explicitly and alert on it.
• Clock skew across nodes → intermittent expired-challenge failures that are painful to diagnose.
• Replay, if single-use is left off and the expiry window is generous.
• Conversion/accessibility regression — proof-of-work costs real seconds on low-end mobile. Measure abandonment, don't assume.

Ramp-up. ~0.5 day for a Laravel-comfortable engineer to ship one form. Add 1–2 days for Livewire/Inertia/SPA token plumbing, and 1–2 days more if we commit to single-use with a new storage path and expiry cleanup. No new infrastructure class is introduced unless single-use is enabled.

Recommendation. Adopt 2.3.0 for a scoped pilot on one public form. Pin the vendor library explicitly. Make the single-use decision before rollout rather than after. Re-review once PoC data on solve time and abandonment is in hand.