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.
@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.
A post was split to a new topic: Does honeypot field of form log its results?
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.
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?
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 
I agree with @anon76427325 that custom solution would better fit the cookbook
I was referring to this topic I link to: hCaptcha support in Grav forms? - #8 by ondrejv