Filament Captcha Laravel Package

Technical Evaluation

Architecture fit

• dominion-solutions/filament-captcha is a thin Filament form-field plugin: service provider + config + Blade field wrapping a third-party CAPTCHA provider (reCAPTCHA/hCaptcha/Turnstile-class). Small architectural footprint, standard Laravel package conventions, no persistence layer or background processing.
• Fit is good structurally (drop-in field on login/registration/contact forms), but note the placement: it sits directly in the authentication and public-form submission path. That makes it security-adjacent infrastructure despite being a small UI package, and it should be governed accordingly rather than treated as a cosmetic dependency.

Integration feasibility

• Low effort: composer require, config publish, provider keys in env/secret store, add the field component to the relevant Filament forms. A competent Laravel dev can prototype in under a day.
• The real gate is version alignment, not code. The 1.0.0 release is a single PR titled "modernization Laravel 13," which strongly implies a raised PHP floor, a new Filament major constraint, and dropped support for older Laravel/Filament lines.

Technical risk

• Insufficient changelog for a major bump. 0.2.0 → 1.0.0 with one squashed PR and no migration notes is a semver-significant event with no stated breaking changes. Until the diff and composer.json constraints are read, treat 1.0.0 as breaking by default: possible namespace/config-key/field-API changes and a hard cut on supported framework versions.
• Forward-targeting an unreleased framework line. "Laravel 13" modernization suggests the package now targets a Laravel/Filament version that is not yet our production baseline. Adopting 1.0.0 may force a framework upgrade we have not scheduled; staying on 0.2.0 may leave us on an unmaintained branch.
• Supply-chain and bus factor. Single small vendor org, low release cadence, no visible security policy or disclosure channel from the release notes. For a component that gates form submissions, that is a concentration risk worth naming to security review.
• Third-party provider coupling. Verification is an outbound HTTPS call on form submit: adds p95 latency to auth flows, consumes provider quota, and introduces a runtime dependency on an external SaaS (with GDPR/CCPA implications if that provider is Google).
• Accessibility and compliance. CAPTCHA is a known WCAG 2.2 / European Accessibility Act friction point. Confirm the package's supported providers include a low-friction option and that a documented fallback exists.
• Testability. If there is no test-mode/bypass key, CI and E2E suites will either hit the live provider or be forced to mock internals.

Key questions

1. What exactly broke between 0.2.0 and 1.0.0 — PHP floor, Filament major, config keys, field API, view namespace?
2. Which Laravel and Filament versions does 1.0.0 actually constrain in composer.json, and is Laravel 13 GA or pre-release at that pin?
3. Which CAPTCHA providers are supported, and is the provider abstraction swappable without forking?
4. On provider timeout/5xx/quota exhaustion, does the field fail-open (lets spam through) or fail-closed (blocks legitimate users)? Is that configurable?
5. Is there an official test/bypass mechanism for automated tests and local dev?
6. Secret handling: env-only, or is there a documented path for a secrets manager and key rotation?
7. Does the package make any outbound calls or collect telemetry beyond the verification request itself?
8. License, security disclosure process, and maintainer succession/bus-factor posture?
9. Accessibility: does it support audio/alternate challenges, and does it document WCAG/EAA guidance?
10. Is there a viable fallback (Laravel rate limiting + honeypot, or an in-house field) if this package is abandoned?

Integration Approach

Stack fit

• Assumes a Laravel + Filament admin/panel application with at least one public-facing form (login, registration, contact, comment). If Filament is not already in the stack, this package is not applicable — use Laravel's rate limiter plus a honeypot instead.

Migration path

• Do not upgrade in place. Stand up 1.0.0 on a branch against a staging environment first and diff the published config against the current config/filament-captcha.php; any renamed keys will silently fall back to defaults, which for a security control means silently disabled protection.
• Keep 0.2.x pinned in composer.json (exact constraint) on the current production branch. Pin, don't range, so an unattended composer update cannot pull 1.0.0 into a release.
• If 1.0.0 requires Laravel 13 / a new Filament major, treat the package upgrade as a sub-task of the framework upgrade epic, not as an independent maintenance ticket.

Compatibility

• Verify the PHP floor against our runtime images, and the Filament constraint against our panel version. Filament majors are not cross-compatible at the plugin level; expect a hard split.
• Check that our form definitions use the supported field API — if 1.0.0 renamed the component, every form using it needs a code change, which is the main hidden effort.
• Confirm the provider keys and any CSP frame-src/script-src allowances still match the provider the package renders.

Sequencing

1. Read the PR #26 diff and composer.json; extract the actual breaking-change list. (Blocking — nothing else proceeds until this is done.)
2. Security/legal review of the provider dependency (data residency, consent banner interaction, accessibility sign-off).
3. Prototype on a branch; validate test-mode bypass and CI behavior.
4. Staging soak with failure injection: simulate provider timeout, 5xx, and invalid key; confirm the chosen fail-open/fail-closed behavior.
5. Ship alongside the framework upgrade window; feature-flag the field so it can be disabled per panel without a deploy.
6. Retire 0.2.x only after a full release cycle on 1.0.0.

Operational Impact

Maintenance

• Low ongoing code maintenance, but non-zero governance: this package's release cadence is sparse and its version history just went major with minimal notes. Budget a recurring quarterly "is this still maintained and still pinned correctly" check rather than assuming passive stability.
• Add it to the dependency register with an explicit owner, current pin, and a documented fallback plan.

Support

• Support is GitHub-issues-only from a small vendor. There is no SLA and no commercial escalation path. Internal runbook must therefore cover "package is broken/abandoned" — the fallback being rate limiting plus a honeypot, or swapping to a first-party provider SDK behind our own field.
• Key rotation and provider account ownership must sit with us, not the vendor; document who holds the provider accounts and where keys live.

Scaling

• Verification is a synchronous outbound call per submission. At login-form volumes this is negligible; on high-traffic public forms it becomes a per-request external latency tax and a provider quota line item. Model expected submissions/month against the provider tier before launch.
• Horizontal scaling is otherwise unaffected — the package is stateless.

Failure modes

• Provider outage → either blocked logins/registrations (fail-closed) or an open spam gate (fail-open). Both are business-visible; choose deliberately and alarm on verification error rate.
• Misconfigured or rotated-but-not-redeployed keys → silent total block on auth. Needs a synthetic check that exercises the form.
• Silent config-key drift on upgrade → CAPTCHA rendered but unenforced. Needs an assertion in integration tests, not just a visual check.
• CSP or consent-banner changes breaking the widget → submissions fail with no obvious error. Include the field in browser-level smoke tests.
• Package abandonment → no patches for a security-relevant component. Mitigated only by the documented fallback.

Ramp-up

• Engineering: hours. One developer can integrate and test the field in a day, plus roughly a day for the failure-mode and test-bypass work.
• Cross-functional: the longer pole is legal/privacy (provider data handling, consent) and accessibility review — plan one to two weeks of calendar time, largely waiting, not working.
• Support/on-call: brief runbook addition covering "CAPTCHA failing → check keys, provider status page, and the toggle" — a single page, but write it before launch, not after the first incident.