Honeypot Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. There is no service provider, no config/honeypot.php, and no facade. composer require rattler/honeypot-bundle in a Laravel app will pull it in but give you nothing wired up — the bundle's HoneypotBundle class expects Symfony's Kernel/Bundle registration and the Symfony Form component. Treat this as a reference implementation of the honeypot technique, not a dependency.

• Look first at the bundle's form type extension and its validator constraint. That is the entire mechanism: a hidden field registered against forms, plus a constraint that rejects submissions where the field is non-empty. Read those two classes; they are the whole package.
• State check before committing time: last release 2016-06-15, 4 stars, 0 dependents, score 0.02. This is abandoned. There will be no PHP 8.x fixes, no Symfony 6/7 support, and no security patches. Do not build a production dependency on it.
• First use case in Laravel — reimplement the pattern rather than install the package. A minimal version:

// app/Rules/Honeypot.php
class Honeypot implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        if (filled($value)) {
            $fail('Submission rejected.');
        }
    }
}

{{-- resources/views/contact.blade.php --}}
<div aria-hidden="true" style="position:absolute;left:-9999px;top:-9999px;">
    <label for="website">Website</label>
    <input type="text" name="website" id="website" tabindex="-1" autocomplete="off">
</div>

$request->validate([
    'email' => ['required', 'email'],
    'website' => [new Honeypot], // the honeypot field
]);

That gets you 90% of what the bundle does, in ~15 lines, with no abandoned dependency.

Implementation Patterns

The bundle encodes three patterns worth understanding, whether or not you run any of its code.

1. Hidden-field honeypot. A form field that is hidden via CSS (not type="hidden") is filled by naive bots that parse the HTML and populate every input. Humans never see it, so any value in it means "bot." The bundle registers this field automatically on forms via a form type extension — convenient in Symfony, irrelevant in Laravel where you control the Blade template directly.

2. Validation-constraint rejection. The bundle ships a constraint that fails validation when the honeypot field is populated. In Laravel this maps cleanly to a custom rule (above) or a FormRequest withValidator hook. Prefer the rule — it composes with the rest of $request->validate().

3. Time-trap (adjacent pattern, not in the bundle but commonly paired). Bots submit instantly; humans take seconds. Stamp a signed timestamp into the form and reject submissions under ~2 seconds. In Laravel:

// On render: <input type="hidden" name="ts" value="{{ encrypt(now()->timestamp) }}">
$started = decrypt($request->input('ts'));
abort_if(now()->timestamp - $started < 2, 422);

Integration tips for a Laravel app:

• Put the honeypot field name behind config (config/honeypot.php) so you can rotate it when bots learn it.
• Use position:absolute; left:-9999px plus aria-hidden="true" and tabindex="-1" — never display:none alone, since some sophisticated bots skip non-rendered inputs.
• Don't name the field honeypot or _trap. Use something plausible (website, company, fax) so bots fill it.
• Fail silently — return a 200 with a generic success message rather than a 422. Telling a bot it failed lets it tune.

Gotchas and Tips

• Framework mismatch is the headline gotcha. Every Symfony convention in this bundle — Bundle class, DependencyInjection/, form type extensions, service tagging — has no direct Laravel equivalent. You cannot "just install it." Budget for a rewrite, not an integration.
• The package is dead. 2016 release date, 4 stars, 0 dependents. Assume unpatched incompatibilities with modern PHP and zero CVE response. If you fork it, you own it.
• Autofill false positives. Browser password managers and accessibility tools will happily fill a hidden "website" field on some configurations. Keep the field autocomplete="off" and monitor rejection rates — a sudden spike means real users are being blocked.
• Accessibility. A field hidden with display:none is invisible to screen readers and to many bots — defeating the purpose. aria-hidden="true" + off-screen positioning is the safer combination. Never required a honeypot field; a human can't fill it.
• Don't rely on a single signal. Modern bots defeat naive honeypots. Layer honeypot + timestamp + rate limiting (RateLimiter::attempt) + a real captcha only on suspicious traffic.
• Debugging rejections. Log rejected submissions with the offending field name and user agent before you abort(). When the client asks "why did my form fail," you'll want the evidence. Add a Log::info('honeypot_reject', [...]) line inside the rule.
• Extension points worth copying from the bundle: it separates field registration from validation, which is the right seam. In your Laravel rewrite, keep those separate too — a Blade partial for the field, a Rule for the check — so you can swap the field name or the validation strategy independently.
• Config quirk to avoid: if you do build config around this, don't cache the honeypot field name in config:cache in a way that ties the name to a deploy. Rotation should not require a full cache clear.