Altcha Bundle Laravel Package

Technical Evaluation

Architecture fit — mismatch, unchanged as of 3.1.0. huluti/altcha-bundle is a Symfony bundle, not a Laravel package. Its integration surface is Symfony-specific: it registers as a Bundle subclass, wires services through the Symfony DI container, and relies on Symfony's configuration tree, autoconfiguration tags, and typically a Flex recipe. Laravel has no equivalent bundle lifecycle — no Bundle interface, no extension/config-dump mechanism, no recipe system. Dropping this into a Laravel app would mean pulling symfony/http-kernel, symfony/dependency-injection, and symfony/config into a framework that already has its own container, which is a hard no for a production Laravel service. This package cannot be adopted as-is in a Laravel stack. Nothing in 3.1.0 touches the bundle's framework coupling, so the verdict is unchanged.

What 3.1.0 actually delivers. Two things, neither structural:

• Fix #70 type exception (PR #71) — a correctness fix. Good to see, but a type-exception fix in a 3.x line is also a signal the package is still settling; it argues for "read as reference," not "depend on it."
• Support CSP (PR #73, authored by Huluti) — the substantive item. The bundle now presumably emits nonce-aware or CSP-compatible asset/script handling for the widget. This does not help us, because we are not using the bundle — but the underlying problem it solves is real for the build we are recommending (see Integration Approach). Treat it as confirmation that CSP is a genuine integration concern, not as a feature we inherit.

Provenance note. The 3.1.0 changelog shows Huluti (the original namesake author) contributing to tito10047's repository, which is consistent with a maintainer transfer or active upstream collaboration rather than an abandoned fork. That's a mildly positive signal for the bundle's health, but it does not change the adoption math: still ~20 stars, 0 dependents, single-maintainer, and still the wrong framework.

What is portable. Altcha itself is a protocol, not a framework feature. The server side is a small, well-defined flow: issue a signed challenge (salt + SHA-256 proof-of-work parameters, HMAC-signed), receive the client's solved payload, then verify the hash, the HMAC signature, and the expiry. That logic is ~100 lines and framework-agnostic. The client side is a Web Component (<altcha-widget>) loaded from CDN or npm. Both are directly usable in Laravel via a service class, a validation rule, and a Blade component — no Symfony dependency required.

Integration feasibility: high, but not via this package. Realistic paths, in order of preference:

1. Official altcha-org/altcha PHP server library + a thin Laravel wrapper (validation rule altcha, Blade component, config file for HMAC secret and difficulty). Lowest risk, smallest owned surface.
2. Port the bundle's logic into a Laravel service provider — borrow the challenge/verify semantics, discard the Symfony plumbing. Worth reading 3.1.0's CSP change here specifically: it likely documents the exact header/asset shape the widget needs.
3. Adopt an existing Laravel-native Altcha package if one passes review; otherwise build in-house (~1–2 dev days).

Technical risk: low protocol risk, elevated supply-chain risk. Repository metadata remains the red flag set: package name huluti vs. URL tito10047, ~20 stars, 0 dependents, and a release history whose dates should be reconciled against the actual registry before anyone cites them. A single-maintainer package with zero downstream consumers is not a dependency you take on Laravel-side; it's a reference implementation you read. The 3.1.0 fix releases slightly improve the "is it maintained" answer without improving the "should we depend on it" answer.

Key questions for the team:

• Is the goal "add bot mitigation" or "add this package"? If the former, the framework mismatch makes this a dead end and the official PHP lib is the answer.
• What is our current CSP posture? If we ship a strict script-src, the widget needs a nonce or hash, and the WASM proof-of-work path may need wasm-unsafe-eval. This is now the highest-likelihood integration blocker and should be settled before the spike ends, not after.
• Do we have a compliance requirement (WCAG, GDPR) that the widget's JS/WASM path must satisfy? Accessibility and no-JS fallback need explicit sign-off.
• What is the threat model — casual form spam or targeted automation? Proof-of-work raises cost per request but does not stop a determined attacker with cheap compute.
• Who owns the wrapper if we build it? A two-day build becomes a permanent maintenance line item.

Integration Approach

Stack fit. Nothing about this bundle fits a Laravel stack. Laravel's equivalents — service providers, config/*.php, Validator::extend, Blade components, middleware — have no mapping to Symfony's bundle/extension/compiler-pass model. Treat the bundle as documentation of the protocol, not as a dependency.

Recommended build. Three small pieces:

• config/altcha.php — HMAC secret (from env, rotated), algorithm, cost/difficulty, challenge TTL.
• App\Services\Altcha\ChallengeService — issues signed challenges; verify(string $payload): bool checks hash, signature, and expiry.
• App\Rules\Altcha validation rule + a <x-altcha /> Blade component wrapping the self-hosted widget script. Register the rule so it composes with existing FormRequest validation.

CSP — now an explicit build task. 3.1.0's CSP support is the clearest evidence that this is non-trivial on the Symfony side, and we get none of it for free. Budget it:

• Self-host the widget bundle and serve it same-origin; avoid unsafe-inline by emitting a per-request nonce (Laravel's Vite::useCspNonce() / a CspNonce helper) into the component's script tag.
• Verify whether the proof-of-work path requires script-src 'wasm-unsafe-eval' in our target browsers, or whether Altcha's pure-JS fallback lets us avoid it. Prefer avoiding it — an unsafe-eval-class carve-out on every page is a poor trade for bot mitigation.
• Confirm no connect-src or worker-src additions are needed (self-hosted means no CDN origin, which is a second reason to self-host).
• Add a CSP-violation smoke test to CI; report-uri/report-to collection during shadow mode is the cheapest way to catch this before users do.

Migration path. There is no migration — this is greenfield. If a legacy captcha (reCAPTCHA/hCaptcha) is in place, run Altcha in shadow mode on one low-risk form for 2–3 weeks: collect pass/fail, false-positive, and CSP-violation rates without blocking submissions, then flip to enforcing.

Compatibility concerns to test explicitly:

• Livewire / Inertia. The challenge token is single-use. Any failed validation that re-renders the form invalidates the token and will block the user on retry unless the widget is explicitly reset. This is the single most common integration bug and must be in the acceptance criteria.
• Multi-tab and back-button. Same single-use problem; each form instance needs its own challenge.
• CSP / strict script-src. See above — the failure mode is silent (widget never renders, form never submits), so test under our production headers, not a dev default.
• PHP/Laravel versions. Irrelevant if you skip the bundle; if you don't, the bundle's Symfony version constraints will dictate your PHP floor and may conflict with Laravel's own constraints.
• CDN availability. Self-host the asset so a CDN outage is not a form-submission outage.

Sequencing.

1. Spike (1 day, +½ day for CSP): official PHP lib + self-hosted widget + our production CSP headers on a throwaway branch; confirm verify flow end-to-end and confirm no unsafe-eval needed.
2. Build the wrapper (1–2 days) + tests for expired, tampered, and replayed payloads; one test asserting the form still submits under our CSP policy.
3. Shadow-mode on contact/registration (2–3 weeks), collecting CSP violation reports alongside pass/fail.
4. Enforce, then extend to password reset and any unauthenticated write endpoint.
5. Retro: measure spam reduction against the shadow baseline; decide whether to keep or adjust difficulty.

Operational Impact

Maintenance. If we build the wrapper, we own it — roughly a few hours per quarter for dependency bumps plus whatever the widget's JS surface costs, plus a re-check whenever we tighten CSP. That is genuinely small, and far cheaper than owning a Symfony-bundle fork. Do not fork huluti/altcha-bundle into the Laravel app; that path produces a permanent, undocumented divergence.

Support. Effectively none. ~20 stars, zero dependents, and a single maintainer mean there is no vendor, no SLA, and no meaningful community backstop. The correct posture is: the protocol is stable and simple enough to reimplement, so do not depend on this package for anything. Track upstream altcha-org for protocol changes; watch this repo's changelog as free intelligence on edge cases (3.1.0 just told us CSP is one). 3.1.0's two-line changelog is exactly the level of signal you get from a package like this — enough to notice, not enough to rely on.

Scaling. Favourable. Verification is a SHA-256 hash comparison plus an HMAC check — microseconds, no I/O, no external service call, no per-request vendor cost. The expensive work (solving the proof-of-work) happens on the client, which is the whole point versus reCAPTCHA. Two caveats: the HMAC secret must be shared across all app instances (env/config, not per-node), and Altcha is not a rate limiter — keep throttle middleware in front of every protected endpoint, because PoW raises cost per request but does not cap request volume.

Failure modes to instrument:

• CSP violation — widget script or WASM blocked by our own headers; presents as "form has no challenge, submit fails silently." Highest-priority new entry post-3.1.0; instrument CSP reports.
• Expired challenge — TTL too short relative to slow mobile solve times; log verify failures by reason to tune.
• Clock skew — expiry checks against server time; NTP drift across nodes produces intermittent, hard-to-reproduce failures.
• Single-use token on retry — the Livewire/back-button case above; surfaces as "form won't submit after a validation error."
• Widget script failure — proxy or ad-blocker heuristics; submission silently impossible. Self-host and add a visible error state.
• WASM/JS disabled — accessibility and hardened-browser users locked out; decide the fallback policy up front.
• Determined bots — PoW is a cost multiplier, not a wall; expect sophisticated actors to absorb it. Layer with rate limiting and behavioural checks.
• Secret rotation — rotating the HMAC secret invalidates all in-flight challenges; rotate during low traffic with an overlap window.

Ramp-up. One engineer, roughly half a day to understand the protocol and the widget API, then 1–2 days to build and test the Laravel wrapper, plus up to half a day on CSP given it's now a known sharp edge. No framework-specific expertise needed beyond standard Laravel validation, Blade, and response headers. The bundle's Symfony idioms will cost a reviewer an hour of confusion before concluding it's not applicable — budget that as deliberate spike time rather than discovery-by-surprise.

Recommendation. Unchanged by 3.1.0. Do not adopt huluti/altcha-bundle on a Laravel codebase — the framework mismatch is disqualifying and the adoption signals (low stars, 0 dependents, ambiguous repo provenance, still fixing type exceptions) don't justify working around it. The CSP support in 3.1.0 is worth reading as documentation for our own widget integration, not as a reason to reconsider. If Altcha is the right bot-mitigation choice, implement the challenge/verify flow directly against the official PHP library behind a Laravel validation rule and a self-hosted, nonce-aware widget. Cost is low, risk is contained, and ownership stays internal.