hCaptcha support in Grav forms?

I’m the EU it’s increasingly harder to sell to people that we use Google rechaptcha in our forms due to tracking and data collection. Are there plans to support hCaptcha? Which is more privacy friendly.

1 Like

@AquaL1te, The Grav team will know better then the community… You will probably have a better chance on a final answer at the repo of Grav.

There’s a PR open since April, so maybe some day

2 Likes

There is always a way how to use forms without captcha 99% spam free. The solution I’m using:

  1. create a unique ID for the input which is half of the information
  2. use a custom field to submit the second half of the ID
  3. use a custom plugin to join those two fields

works for me seamlessly for few years already without distracting the user with captcha

Could you elaborate? Do you have 2 hidden inputs each submitting halves of ID? I don’t see how this would prevent bots, so I assume I misunderstood what ID is used as submission and what ID is used as input id attribute :thinking: If it’s used as an attribute, then how do you check it after submit? Sorry, but from your description I just don’t understand at all how this should work :confused:

@AquaL1te I am also in EU.

CNIL, the French DPA, confirmed that reCaptcha cannot be used without asking prior user consent as terms and conditions of Google show that reCaptcha’s purposes of the data processing are not only security but other uses.

The same reasoning should apply to hCaptcha as their data collection also have purposes other than security (image labeling…).

It might be wise, in EU, to refrain from using hCaptcha as well.

1 Like

No captcha is not an option for me. I already get a lot of spam. I’m using the honeypot option of the forms plugin and the DNS plugins that use spamhaus, which also blocks some messages. But I still get about 5 spam mails a week. Geo blocking Russia also helps, but it’s a bit extreme.

hCaptcha does seem to respect the GDPR more, but is not based in the EU.

This one is based in the EU and gives some good impressions.

This is the form example:

title: ‘Contact Form’
form:
name: contact
action: /form/contact
template: form-messages
refresh_prevention: true
classes: denuo
fields:
name:
type: honeypot
UthcCKLVLEkr:
type: text
label: Name
placeholder: ‘Fist and Last name’
autocomplete: name
validate:
required: true
message: ‘Enter your name’
UthcCKZXaFMl:
type: text
label: E-mail
placeholder: your@email.com
validate:
type: email
required: true
message: ‘Enter your email’
buttons:
submit:
type: submit
classes: ‘btn btn-danger’
value: ‘Submit’
process:
azrlogicapp:
formname: WebContact
hash: UthcCK
formtype: Contact
map: ‘{“name”:“LVLEkr”,“email”:“ZXaFMl”}’
display: thankyou

There is a random ID (consisting of 2 parts) for the form elements (not describing their usage) + a standard one with ID “name” (bots are usually looking for the common IDs). custom plugin (azrlogicapp) does the processing and there are two parts in the plugin config (marked bold above):

  1. hash: contains the first part of the input ID (same for all inputs in the form)
  2. map: the second part of the ID.

plugin later translates this into the “meaningful” ID and does the processing. Plugin evaluates if the “name” ID is empty or not - if it is not empty = bot. The idea behind this is not to have real ID/input names available in the form.

not bulletproof but will avoid 99% bots. As I said using this solution 3+yrs with almost zero spam. And I don’t need to bother users with the captcha,…

2 Likes

Could you please use code blocks for that? I believe I have this already in place, but it’s better readable with the backticks in markdown.

I find the documentation about the honeypot a bit short. These extra things you’re doing with it are not described there. Where did you get this information to do it like this?