Symfony Altcha Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle (druidfi/symfony-altcha-bundle), not a Laravel package. That distinction dominates the evaluation: the release under review wraps the ALTCHA proof-of-work CAPTCHA, a privacy-preserving alternative to reCAPTCHA/hCaptcha that requires no third-party script or user tracking. The underlying protocol is small and framework-agnostic — issue an HMAC-signed challenge, let the browser solve a SHA-256 PoW, verify the submitted payload server-side with replay protection — so the concept fits a Laravel stack cleanly. The packaging does not: service providers, bundle extension config, and Symfony's RateLimiter component have no direct Laravel equivalents. Assume this is a reference implementation to port or a candidate for a thin Laravel adapter, not a composer require-and-go dependency.

Integration feasibility. Moderate-to-high. The verification path is a handful of HMAC and hash comparisons plus a cache-backed replay guard; a TPM can reasonably scope this as a 5–10 day port covering config publishing, a service provider binding, middleware/validation rule, Blade component for the widget, and tests. The new IP rate limiting on the challenge endpoint is the most substantial addition in 1.0.5 and is also the least portable: it is implemented against Symfony's RateLimiter and will need to be re-expressed with Laravel's RateLimiter facade and a shared cache store. Display mode support appears to be configuration/rendering surface for the widget (inline, floating, etc.) and should port directly.

Technical risk. Framework mismatch is the headline risk and it is architectural, not incidental. Secondary risks: (1) 1.0.5 is a patch release with no breaking changes implied by the changelog, so upgrade risk within the Symfony lineage is low — but that is not the risk we carry; (2) the project has a very small contributor base (two named contributors, plus a Renovate bot), so bus factor and long-term maintenance depth are thin; (3) a self-hosted PoW gate is now on the critical path of your login/registration/signup funnel — a misconfiguration fails closed and blocks real users; (4) the new rate limiter introduces a hard dependency on shared cache state, which changes the failure semantics of the challenge endpoint.

Key questions.

• Is the intent to adopt the Symfony bundle via a bridge, fork it, or reimplement the protocol in a small first-party package?
• What is the actual Laravel and PHP version floor we must support, and does the underlying ALTCHA PHP dependency constrain it?
• Does IP rate limiting need to sit behind a trusted proxy/CDN config to avoid throttling everyone behind one egress IP?
• What is the fallback if the cache store is unavailable — fail open (weaker protection) or fail closed (outage)?
• Is there an accessibility requirement that a PoW challenge must satisfy, and does the widget meet it?

Integration Approach

Stack fit. Good at the protocol level, poor at the package level. ALTCHA's value proposition — no Google dependency, no cookie consent implications, GDPR-friendly — aligns well with most Laravel product contexts, particularly EU-facing ones. The rate-limiting addition in 1.0.5 is directly relevant to Laravel teams, since login and registration endpoints are exactly where abuse lands.

Migration path. Recommended sequencing: (1) prototype verification server-side only, in a single feature test, against a captured ALTCHA payload to confirm the signature/HMAC contract; (2) wrap it in a Laravel validation rule or middleware, keeping the widget script vendored or self-hosted rather than CDN-loaded; (3) port the IP rate limiting from 1.0.5 onto Laravel's RateLimiter with the cache store explicitly configured; (4) port display-mode configuration as a published config file plus a Blade component with props; (5) roll out behind a feature flag on one low-risk form before touching login.

Compatibility. Verify the bundle's PHP constraint and Symfony major (6.x vs 7.x) against our runtime — not because we will install it, but because it signals which language features the reference code uses and therefore how much rewriting the port needs. Pin to the 1.0.x line and track upstream releases manually; the Renovate bot added in 1.0.5 is a dependency-hygiene signal, not a substitute for our own review cadence.

Sequencing risk. Do not attempt to introduce the rate limiter and the CAPTCHA simultaneously. The rate limb is separable and lower risk; if the PoW widget causes funnel friction, we want to have already isolated which change caused it.

Operational Impact

Maintenance. We would own the ported code, not the upstream bundle, which is the correct trade for a ~300-line surface but must be stated plainly to stakeholders. Upstream 1.0.5 gives us a changelog to track but no upgrade path we can consume directly. Budget a recurring 1–2 hours per quarter to read upstream diffs and decide whether to backport.

Support. No commercial support; community-only, small contributor set. Escalation for a production incident is "we read the source," which is acceptable given the code size but should be documented in the runbook.

Scaling. Favourable. PoW verification is stateless and cheap for the server — the cost is pushed to the client's CPU, which is the entire point. The one stateful element is replay/solution tracking plus the new IP rate limiter; both need a shared cache (Redis) rather than the per-node array store, or throttling and replay protection silently diverge across instances.

Failure modes. Enumerate explicitly: cache store unreachable (define fail-open vs fail-closed per endpoint); clock skew breaking HMAC validity windows between app servers; expired challenges at the edge of the solve timeout on low-end mobile devices; shared-NAT or corporate-proxy egress IPs tripping the new limiter and blocking legitimate cohorts; ad-blockers or CSP policies suppressing the ALTCHA script and leaving users with an unusable form and no error surfaced.

Ramp-up. Low for a mid-level Laravel engineer — the concept is well documented upstream and the protocol is readable. The cost is in the plumbing (middleware, config, Blade component, tests) and in getting the failure semantics right, not in understanding ALTCHA. Allocate a half-day of onboarding plus a documented runbook entry covering the failure modes above.