Filament Captcha Field Laravel Package

Technical Evaluation

Architecture fit. Unchanged by v0.1.1. The package is a Filament form field: a Field subclass plus a Blade view that renders the captcha widget client-side and a server-side validation rule that verifies the response token against the captcha provider's API. That is the correct shape for a Filament plugin — it slots into the existing form component lifecycle, participates in validation, and can be dropped into any schema. Architecturally it is a low-ceremony addition rather than a platform commitment.

Integration feasibility. The material constraint is still version alignment, and v0.1.1 does not address it. The release only widens the laravel/framework constraint to include Laravel 10. Laravel 10 shipped in February 2023 and is already supported by Filament 2.x, so this release is consistent with — and evidence for — the package remaining on the Filament 2 track. It says nothing about filament/forms (still presumed ^2.x) or livewire/livewire (still presumed ^2.x). Filament v3 requires Livewire 3 and changed form schema APIs and asset registration (FilamentAsset); v4 is further out. Expect a Composer conflict on any modern Filament install. The Filament major constraint remains the gating question for the whole evaluation, and v0.1.1 leaves it unanswered.

What v0.1.1 does change is the maintenance signal: the artifact is not fully abandoned, and the maintainer's priority ordering is now visible — Laravel version compatibility was backported ahead of any Filament 3 work. That is a reasonable bet for a package whose users are on legacy panels, but it confirms you should not expect a modern-Filament path from upstream on any useful timeline.

Technical risk.

• Thin maintenance. One release in over two years, one line of change, 18 stars, zero dependents. There is a pulse, but no production surface area and no community pressure to fix regressions. v0.1.1 is a dependency-widening commit, not a quality signal.
• Versioning discipline. The package is pre-1.0 (0.1.x). Semver gives no stability guarantee here: a "patch" bump can carry breaking changes. Pin exactly and review every release diff — the entire v0.1.1 delta is one constraint, which is easy to audit and cheap to mirror if you vendor.
• Provider coupling. Still unknown which provider(s) are supported (reCAPTCHA v2/v3, hCaptcha, Turnstile) and whether verification is server-side. A client-only check is not a security control.
• Availability coupling. Captcha verification introduces a synchronous third-party HTTP call into your form submission path. Provider or network failure can block every legitimate submission on the form it protects.
• Supply chain. Bundled/published JS assets or CDN references need review; a captcha field executes third-party script on your public pages. Nothing in v0.1.1 touches asset registration — worth noting, because if asset registration is the Filament 3 blocker, this release confirms it was not addressed.
• Testability. Without a fake/bypass driver, the field makes feature tests and CI brittle or impossible.

Key questions.

1. Which Filament major(s) and Livewire version does composer.json support after v0.1.1? (The Laravel answer is now known: up to 10. The Filament answer is not.)
2. Which captcha providers, and is the token verified server-side with a timeout?
3. Is there a configurable bypass / fake driver for tests and local dev?
4. Are the widget assets published locally or loaded from a CDN?
5. What is the documented behavior when the provider is unreachable — hard fail, soft fail, log-and-allow?
6. Is v0.1.1 a one-off patch by a maintainer still engaged, or a drive-by fix? Is there any stated intent to support Filament 3/4?
7. Does the Laravel 10 constraint widening change anything in the verification code path (HTTP client, Guzzle pin), or is it a composer.json-only commit?

Integration Approach

Stack fit. Laravel + Filament. Note the tension: Filament is primarily an admin-panel framework, and captcha is almost always needed on public forms. The package only pays off if you already render Filament forms on unauthenticated pages (standalone form usage) or have a public-facing panel (registration, contact, support intake). If your captcha need is a plain Blade/controller form, this package is the wrong tool entirely. v0.1.1 does not change this.

Migration path. Two options, sequenced by the version answer:

• If on Filament 2 + Laravel 10 and not upgrading: v0.1.1 makes this the most comfortable it will be — adopt directly, pin the exact version (0.1.1), and treat it as frozen.
• If on Filament 3/4 (the likely case): v0.1.1 does not unblock you and there is no signal that upstream intends to. The realistic path remains vendoring the field into the application — copy the Field class and Blade view into app/Filament/Forms/Components/ and adapt to the current API. The artifact is small (roughly a component, a view, a validation rule, and a config entry), so this is a low-cost port rather than a rewrite.

Compatibility checks before committing. PHP version, filament/forms constraint, livewire/livewire constraint (v2 vs v3), and whether the captcha provider SDK/HTTP client is compatible with your pinned Guzzle. Re-run composer why-not against the target Filament version to confirm v0.1.1 changed nothing — the expected outcome is that the conflict is now isolated to filament/forms and livewire/livewire only.

One positive side effect of v0.1.1: if you are on Laravel 10 with Filament 2, the previously ambiguous Laravel-version question is closed, which shortens the spike. It does not shorten the port.

Sequencing.

1. Spike: install 0.1.1 against your actual stack in a scratch branch; capture the exact conflict set. Budget half a day — less than before, since the Laravel axis is resolved.
2. Decide vendor-vs-fork based on the port cost (likely < 1 day). If the spike succeeds on your stack, prefer pinning over forking.
3. Implement server-side verification with an explicit timeout and a named failure policy.
4. Add a fake driver bound in the test environment so CI never calls the provider.
5. Roll out to one low-risk public form, then the rest.
6. Only then decide whether to also protect higher-value flows (registration, password reset).

Testing. Non-negotiable: feature tests asserting that (a) a valid token passes, (b) an invalid/expired token fails, and (c) a provider timeout produces the documented behavior rather than a 500.

Operational Impact

Maintenance. Treat this as you own it. v0.1.1 is a marginal improvement to the signal — it proves the maintainer will accept a narrow dependency-compatibility patch — but one release in two-plus years, 18 stars, and zero dependents still means no downstream bug reports have been filed and bus factor is effectively one. There is still no stated roadmap for Filament 3/4. Budget for an annual compatibility pass against each Filament major, and assume you will absorb any security fix in the widget or verification logic yourself.

Support. GitHub issues only, no SLA, no commercial backing. Escalation path is "read the source and patch it," which is acceptable only because the surface is small. Note that the one observed maintenance behavior — widening a framework constraint rather than addressing a UI-framework major — tells you what kind of upstream fixes to expect.

Scaling. Unchanged. Each submission triggers an outbound verification request: expect 100–500ms added latency and provider-side rate limits and quotas. At high submission volume (e.g., a public contact form under bot pressure), you can hit provider QPS caps and start failing legitimate users. Plan for the provider's quota tier and consider per-IP throttling upstream so the captcha is a second line of defense, not the first.

Failure modes to design for explicitly.

• Provider outage or network timeout → submissions blocked. Choose fail-open (log, allow, alert) vs fail-closed per form criticality; fail-closed on login is a self-inflicted outage.
• Missing or wrong keys in a new environment → silent blank widget or universal rejection. Add a boot-time config assertion.
• Token expiry and replay — tokens are short-lived (~2 min); slow users on long forms will fail. Position the field last in the schema.
• Client-side blocking (privacy extensions, corporate firewalls, CSP) → users cannot submit at all. Needs a documented fallback and CSP allowances for the provider domain.
• Accessibility — audio/alternative challenge must be enabled; a captcha that locks out screen-reader users is a compliance problem.
• Asset staleness — published JS from 2023 (untouched by v0.1.1) against a provider that has since changed its API.
• Silent drift on an unpinned dependency — a pre-1.0 package can ship a breaking change in a patch bump. Pin 0.1.1 exactly in composer.json.

Ramp-up. Low. A mid-level Laravel developer can wire the field, publish assets, and set env keys in roughly half a day. The real cost remains the port if you are on Filament 3/4, plus the test harness and failure-policy decisions — budget 2–3 days end to end including staging validation with live keys.

Recommendation. Unchanged in direction, slightly firmer in evidence. Do not take a hard dependency on this package unless you are already pinned to Filament 2 + Livewire 2, in which case v0.1.1 makes it safe to pin exactly and accept as frozen. Otherwise evaluate it as reference source code: if the provider choice and implementation match your needs, vendor and modernize the field into your application, add a fake driver, and define the provider-outage policy. Do not let it gate a Filament upgrade — v0.1.1 widened Laravel support without touching Filament, which is a clear signal that upstream is maintaining a legacy track rather than chasing current majors. Given 18 stars, zero dependents, and a one-line release after two years, the opportunity cost of an in-house field (~150–200 lines) remains lower than the cost of owning an unmaintained dependency.