Honeypot field could use better documentation

Continuing the discussion from hCaptcha support in Grav forms?:

I would like to see some more practical examples for the honeypot field. The documentation now seems to me kind of short and doesn't show and explain the mechanism. An example with some explanation would help a lot.

https://learn.getgrav.org/17/forms/blueprints/fields-available#honeypot-field

@AquaL1te, Does the docs prohibit your from implementing honeypot? Not sure what more needs to be said.

Btw. there are loads of docs on the web if you need more background information on the intricacies of a honeypot.

I've seen the confusion in more topics on this forum. So I think it wouldn't hurt to make it a bit more verbose.

Here's my form below. On a weekly basis I get at least 3 spam messages. So my assumption is that it doesn't work, or doesn't protect well enough. Even though I also use the DNS blacklisting from SpamHaus and reCaptcha from Google.

title: Contact
form:
    name: contact
    fields:
        name:
            label: Name
            placeholder: 'Enter your (first) name'
            autocomplete: true
            autofocus: true
            type: text
            validate:
                required: true
                message: 'Your (first) name'
        email:
            label: Email
            placeholder: 'Enter your email address'
            type: email
            validate:
                required: true
                message: 'Your email address'
        location:
            label: Region
            placeholder: 'Enter your region (city, municipality or province)'
            type: text
            validate:
                required: false
        message:
            label: Message
            placeholder: 'Enter your message'
            type: textarea
            validate:
                required: true
                message: 'Your message'
        privacy-policy:
            label: 'Have you read our [privacy statement](/privacy-verklaring?target=_blank) and do you agree?'
            type: checkboxes
            markdown: true
            options:
                agreed: 'I''ve read it and I agree'
            validate:
                required: true
                message: 'Privacy policy'
        g-recaptcha-response:
            label: Captcha
            type: captcha
            recaptcha_not_validated: 'Captcha not valid!'
        honeypot:
            label: ID
            type: honeypot
    buttons:
        submit:
            type: submit
            value: Send
        reset:
            type: reset
            value: Reset
    process:
        dns-blacklist: true
        captcha: true
        email:
            subject: '[Contactformulier] {{ form.value.name|e }}'
            body: '{% include ''forms/data.html.twig'' %}'
        save:
            fileprefix: contact-
            dateformat: Ymd-His-u
            extension: txt
            body: '{% include ''forms/data.txt.twig'' %}'
        message: 'Thanks for your message! If you don''t see a message from us in your inbox within a few days, check then your spam folder. Maybe it ended up there unintentionally.'
        display: thankyou
process:
    markdown: true
    twig: true
cache_enable: false
page-toc:
    active: false
---

# Contact form 
##### Please leave a question or suggestion, you can also do this via our [social-media](/social-media). Also check our [internal search](/search) and [FAQ](/tzm/faq), maybe your question has already been answered.

The example in the documentation shows:

fields:
    - name: honeypot
      type: honeypot

Is it then fair to assume this is all that's needed to make it work? A spam bot would fill in the field 'honeypot' of type honepot, and when this field contains a value, the message is not sent? Because if I do understand this mechanism correctly, then it's just not a solution that blocks all spam. My implementation has a field called ID, of type honeypot.

@AquaL1te,

I’ve seen the confusion in more topics on this forum. So I think it wouldn’t hurt to make it a bit more verbose.

Feel free to create a PR to improve the docs as you see fit.

On a weekly basis I get at least 3 spam messages. So my assumption is that it doesn’t work, or doesn’t protect well enough.

Honeypots are not 100% fails save. For example they will not protect a form from humans entering spam manually.

And spambots are getting smarter every day. Eg when using a form with honeypot named 'subject', the generated dom will look like:

<input 
    aria-hidden="true"
    type="text"
    style="visibility:hidden;position:absolute!important;height:1px;width:1px;overflow:hidden;clip:rect(1px,1px,1px,1px);"
    class="form-honeybear"
    name="data[subject]"
    value="" 
/>

I think it has enough hints for skipping it.

@pamtbaau:
Feel free to create a PR to improve the docs as you see fit.

I can do that. However, the mechanism isn't clear to me either. So I would be the least qualified to improve the documentation. Sure, I get what HTML it generates and I get the general idea. But how to make a good honeypot and troubleshoot it is unclear. The topic I link to in the first post shows some tricks that are not documented. Would be cool if that was explained a bit more and other strategies.

It's as simple as it gets. There's no good or bad honeypot field. It's just an invisible empty field, which is checked after submission - if it's not empty, then it's a bot and form fails.

The topic I link to in the first post shows some tricks that are not documented

Your link points directly to honeypot documentation and you're saying it has some tricks shown in that documentation, that are not documented. What?

@AquaL1te,

I can do that. However, the mechanism isn’t clear to me either. So I would be the least qualified to improve the documentation.

The docs on the Honeypot field are sufficient imho. The suggested custom improvement you've linked to (which requires a custom plugin) does not fit there.

There are more improvements to find on the web which could be implemented as an add-on to field Honeypot. The Cookbook section might be a better fit if one wants to add a recipe to the docs.

I was corrected I was checking the wrong link :man_facepalming: I agree with @pamtbaau that custom solution would better fit the cookbook

I was referring to this topic I link to: /forum/forms-blueprints/hcaptcha-support-in-grav-forms-t5390