Livewire Honeypot Laravel Package

Product Decisions This Supports

• Form abuse protection for Laravel/Livewire surfaces: This package provides a low-effort honeypot layer for contact, signup, checkout, and feedback forms. It supports decisions about whether to ship basic bot mitigation in-house or buy a dedicated anti-spam service.
• Build vs. buy for spam prevention: Because the package is small, Laravel-native, and now explicitly tested against the real middleware stack, it is a credible “build-light” option before considering CAPTCHA vendors, WAF rules, or commercial form-protection services.
• Livewire-specific form architecture: The v1.6.0 changes clarify how honeypot fields should bind for Livewire forms using custom wire:model paths. This informs component design decisions — particularly whether forms should use the default <x-honeypot /> or bind to nested form properties.
• Upgrade/support prioritization: The release fixes a regression affecting plain Laravel forms under default ConvertEmptyStringsToNull middleware, and a Livewire security gap where custom-bound honeypots were not actually validated. Product and engineering should prioritize adoption or upgrade review for any Livewire forms using custom wire:model bindings.
• Roadmap signal: The addition of optional validateHoneypot(?string $model, ?string $errorKey) arguments and a real-middleware feature test suggests the package is maturing around documented Laravel behavior rather than only happy-path Livewire usage. It is reasonable to keep it in the roadmap for standard form protection, while monitoring for further breaking changes around trait placement.

When to Consider This Package

Consider adoption when:

• The product runs Laravel and/or Livewire and needs lightweight, low-friction bot protection for public forms.
• You want to avoid CAPTCHA friction for legitimate users and are comfortable with honeypot-style protection as one layer in a broader abuse-prevention strategy.
• Your Livewire forms use <x-honeypot /> with default attributes, or you are prepared to keep custom wire:model bindings and validateHoneypot(model: ..., errorKey: ...) arguments aligned.
• You are on a recent Laravel version where empty hidden fields become null via ConvertEmptyStringsToNull; v1.6.0 fixes this for plain forms.
• You need a package small enough to audit and test without a commercial contract.

Look elsewhere or add complementary controls when:

• You need strong, adaptive bot protection, rate limiting, reputation scoring, or enterprise compliance guarantees. A honeypot alone is not sufficient.
• Your forms require accessibility or UX guarantees that conflict with hidden-field techniques.
• You cannot tolerate upgrade work: v1.6.0 includes behavior changes for the HasHoneypot trait on non-component classes and requires action for Livewire forms using custom wire:model bindings.
• Your Livewire architecture places traits on form objects or non-component classes. The HasHoneypot trait now throws a LogicException there, and the trait must be moved to the component.
• You rely on plain-form validation and previously applied the array_map(fn ($value) => $value ?? '', $request->all()) workaround. It can remain, but the underlying bug is fixed.

How to Pitch It (Stakeholders)

For executives: The package is a small, Laravel-native honeypot layer for reducing basic form spam without adding CAPTCHA friction. The new v1.6.0 release fixes a real production issue where plain Laravel forms could reject every legitimate submission, and closes a security gap in Livewire forms that bound the honeypot field to a custom property. It also adds test coverage that exercises the real Laravel middleware stack. This is a maintenance and risk-reduction release, not a major feature expansion; it keeps the package viable for low-cost form protection, provided teams review custom Livewire bindings and trait placement.

For engineering: Upgrade is recommended if you use plain forms under default Laravel middleware or Livewire forms with custom <x-honeypot wire:model="..."> bindings. Plain forms now work with validate($request->all()) as documented. Livewire forms with custom bindings must pass the same model path and error key to validateHoneypot(model: ..., errorKey: ...) and ensure the bound property starts as an empty string. Forms using plain <x-honeypot /> need no change. The HasHoneypot trait now throws a LogicException when placed on a Livewire form object or non-component class; move the trait and validation call to the component. The existing array_map(...) workaround is harmless but no longer necessary.

For product: This release reduces the risk of false-positive spam rejections on standard Laravel forms and closes a security gap for Livewire forms using custom honeypot bindings. It supports keeping the package as a low-friction anti-spam layer, but it is not a replacement for broader abuse monitoring. Prioritize a quick upgrade review for any public-facing forms, especially those built with Livewire and custom wire:model attributes.