Laravel Altcha Laravel Package

Product Decisions This Supports

• CAPTCHA replacement / bot-mitigation strategy: laravel-altcha is a thin Laravel integration for Altcha, a self-hosted, privacy-first proof-of-work challenge. It directly informs the build-vs-buy decision between reCAPTCHA/hCaptcha/Turnstile (third-party, data-sharing, privacy-compliance overhead) and an in-house or self-hosted challenge mechanism.
• Privacy & compliance roadmap: Because Altcha issues and verifies challenges on your own infrastructure, adopting this package supports GDPR/CCPA-friendly posture on forms — relevant for signup, login, password reset, checkout, contact, and public API abuse surfaces.
• Feature scoping for 2.3.0: The new opt-in single-use solutions mode is the decision-relevant change. It enables replay protection (a solved challenge cannot be resubmitted), which turns Altcha from "raise the cost of automation" into "one challenge, one submission." PMs should scope this as an opt-in hardening flag per form/route rather than a global default, since it adds server-side state and expiry semantics.
• Dependency/upgrade planning: The bump to altcha-org/altcha v2 is an upstream major-version move behind the wrapper. This is an engineering-effort line item (regression testing on challenge generation/verification, widget JS compatibility) and a reason to pin versions in the roadmap.
• Use cases to prioritize: high-volume anonymous endpoints (registration, newsletter, contact, review submission), form-spam reduction without degrading conversion, and API endpoints where you want rate-limit-adjacent bot friction without a vendor.
• Community/vendor-risk signal: A first-time external contributor landing the headline feature, plus active Dependabot maintenance (actions/checkout, fetch-metadata), indicates a maintained but small project — relevant to the "supported dependency" question in architecture reviews.

When to Consider This Package

Consider adopting when:

• You are on a supported Laravel version and want a native, config-driven integration rather than hand-rolling Altcha's challenge endpoint, verification call, and Blade/widget wiring.
• Privacy or data-residency requirements make third-party CAPTCHA vendors (reCAPTCHA, hCaptcha, Turnstile) unattractive, or you need to avoid shipping user data to a third party.
• You want a low-friction bot deterrent that does not force users into image puzzles — proof-of-work is invisible-to-mild for most users and accessible by default.
• You need replay protection: 2.3.0's opt-in single-use solutions is the reason to upgrade from 2.2.x if you're protecting high-value actions (account creation, password reset, coupon redemption) where a captured solution could otherwise be reused.
• You accept a "good enough, cost-raising" threat model rather than hard bot guarantees — Altcha raises automation cost; it is not a behavioral-risk engine.

Look elsewhere when:

• You need managed threat scoring, bot fingerprinting, or ML-based detection — that is a vendor product, not this package.
• You cannot run or scale the challenge/verification path yourself, or you need a CDN-edge/WAF-integrated solution; Altcha runs in your app, so verification is your latency and your availability problem.
• Your traffic profile is dominated by very low-power devices or strict performance budgets where client-side proof-of-work is a UX cost you cannot absorb.
• You need enterprise SLAs, vendor support contracts, or a large maintained security team behind the dependency — this is a small open-source wrapper; treat altcha-org/altcha v2 and the wrapper as dependencies you must track and patch.
• Accessibility or no-JS fallback requirements are absolute and you have not validated the widget behaves acceptably in your environments.

Migration caution for 2.3.0: treat the altcha-org/altcha v2 upgrade as a potentially breaking dependency change. Verify challenge payload shape, verification response handling, and any published config/Blade assets in staging before rollout. Single-use mode is opt-in, so default behavior should be unchanged — confirm that explicitly.

How to Pitch It (Stakeholders)

To executives: We can replace paid, privacy-sensitive CAPTCHA with a self-hosted challenge that keeps user data in our systems. That reduces vendor spend and third-party data-sharing risk on our highest-volume forms. The 2.3.0 release adds one-time-use challenges, which closes the main functional gap (a solved challenge being reused) — a meaningful security improvement for signup and account-recovery flows at effectively no licensing cost. The trade-off is that we own the operational reliability and upgrade tracking of a small open-source dependency rather than buying a supported service.

To engineering: This is a thin Laravel wrapper over altcha-org/altcha, so the integration surface is config, a verification rule/middleware, and a Blade/widget include — low adoption cost. 2.3.0 bumps the upstream library to v2 and adds an opt-in single-use solutions mode (replay protection, requires server-side state with expiry). Action items: pin the version, run a regression pass on challenge issue/verify and the front-end widget, validate that single-use mode is genuinely opt-in and defaults off, and budget for tracking upstream v2 changes since this is a small maintainer team. Do not position it as a bot-detection platform; it is a cost-raising control that should sit alongside rate limiting and existing abuse monitoring.