Grav built-in captcha systems for protecting forms

I’m trying to add a form to a website. To learn about forms step by step, I created a simple empty website, and try to follow instructions in the docs.
The form is working, but I tried to add a basic-captcha and somehow it doesn’t show properly.

The field shows, but instead of the captcha image, it displays the alt text: “human test”.
The url to the captcha image (https://domain.tld/gravsubpath/forms-basic-captcha-image.jpg?v=somelongnumber) seems to return 404.

Anyone has an idea what could be going wrong.

As I said, it’s a fresh install (grav 1.7.48), theme is `quark`.

Page code is the following:

---
title: A Page with an Example Form
form:
  name: contact-form
  fields:
    name:
      label: Name
      placeholder: Enter your name
      autofocus: on
      autocomplete: on
      type: text
      validate:
        required: true

    email:
      label: Email
      placeholder: Enter your email address
      type: email
      validate:
        required: true

    basic-captcha:
      type: basic-captcha
      placeholder: please copy the 6 characters
      label: Are you human?
      validate:
        required: true

  buttons:
    submit:
      type: submit
      value: Submit
    reset:
      type: reset
      value: Reset

  process:
    basic-captcha:
      message: Humanity verification failed, please try again...
    email:
      from: "{{ config.plugins.email.from }}"
      to:
        - "{{ config.plugins.email.to }}"
        - "{{ form.value.email }}"
      subject: "[Feedback] {{ form.value.name|e }}"
      body: "{% include 'forms/data.html.twig' %}"
    save:
      fileprefix: feedback-
      dateformat: Ymd-His-u
      extension: txt
      body: "{% include 'forms/data.txt.twig' %}"
    message: Thank you for your feedback!
    display: thankyou

---

# My Form

Regular **markdown** content goes here...

Thanks a lot in advance to anyone who’d have any suggestions :)

Don't know where the problem is, but I wouldn't bother trying to figure out. Basic captcha is pretty much useless these days. Any decent bot can bypass it.

I guess Karmalakas is right, but I couldn’t resist anyway…

I cannot reproduce the issue using a copy of you snippet on a fresh install of Grav.

Hey @Karmalakas, @pamtbaau, thanks a lot for the answers!

@pamtbaau, your screenshot is exactly what I was expecting to see, but somehow for me it looks like this:

Any idea what could cause this?

@Karmalakas, I was looking for some simple captcha protection for a form, that would not be provided by google or any other big provider, something that can be self-hosted, that’s why I thought “Great!” when I saw grav provided that out-of-the-box. But if it’s outdated now for today’s bots, I wonder what to do. Do you know of some alternative that would be good for today’s bots and easy to implement in grav?

Thanks again for the answers :)

@pamtbaau:
Hard to answer with the little information you’ve provided. If you haven’t changed anything to the fresh install of Grav, I have no clue.

Yes I understand, I didn’t know what other info to provide because it’s really a basic install without any modification apart from creating that test form page. I also had no clue what could be going on and that’s why I wrote this post.
At this point I start wondering if something in the way it’s installed could be the cause of that, even if I really don’t see why/what. I installed it through yunohost which uses [this install script](https://github.com/YunoHost-Apps/grav_ynh/blob/master/scripts/install). At some point I thought it could be a permission issue for the access to the image, but somehow it did not make too much sense because the captcha image is generated programmatically. And all dirs and files permissions seem normal: `gravuser:www-data`. Also, the site is behind a login page, which yunohost handles, so I wonder if that could have an impact, but really don’t see why.

Well I don’t know, it’s strange.

@pamtbaau:
Try the Honeypot field if you don’t want to use big providers. It creates two fields, one visible field for users and one hidden field visible to javascript bots (the honeypot). When the hidden honeypot field has a value, the bear has been caught in the act and Grav will reject the submitted data.

Thanks for this suggestion! I’d never heard of this technique. It’s seems like a sweet solution (it really is, as a honeypot ;)) as as I understand it doesn’t even requests a user interaction, so it’s even more convenient than a captcha.
I’ll try it out.
Do you (or anyone else) have returns of experience using it? and about how well it works against bots?

Thanks a lot @pamtbaau for such a swift answer.

@squeak:
Do you (or anyone else) have returns of experience using it? and about how well it works against bots?

I have no experience with the build-in Honeypot field since I use custom build Contact and Comment forms without using the Form plugin. I've build in three traps which are handled in the following order:

1. A honeypot field with the very common name "Message", which a bot cannot resist.
2. The latest version of Google's reCaptcha, which does not require interaction.
3. Common field value checks eg. correct phone number.

Out of 895 contact forms submitted:

• 382 honeypot
•    3 reCaptcha
• 503 invalid input
•    7 legitimate contacts

I’ve been using reCaptcha v2 (never managed to make v3 work on XHR requests) and still getting spam maybe once a day. Since I also added honeypot \~ a year or two ago, I don’t think I’ve gotten even a single spam mail

Thanks a lot @pamtbaau and @Karmalakas for the returns on experience, I’ll try with the honeypot field and then see if it’s useful to add something more.

@pamtbaau you say you check phone number, may I ask how you perform that check? What ways are there to know that a phone number is valid, apart from sending SMS to people for verification?

@squeak:
you say you check phone number, may I ask how you perform that check? What ways are there to know that a phone number is valid, apart from sending SMS to people for verification?

A "correct phone number" does not equal "existing phone number".... ;-)
I check the format of the phone number.

When using the Form plugin, you could use field validation using regex to check the format of the phone number. You can restrict the format to the format used in your country.

There also is a Tel field, but that field does not add any formatting checks. However, when a mobile user uses the form, the virtual keypad will only show numbers.

Ok, got it, thanks for the explanation :)

@squeak, Any progress you could share? And if solved, would you mind marking the post as solved?

Hey sorry, yes I have had little time to continue developing the site these days, just tested the solution you mentioned and it seem to work great (without test against bots so far).

Just marked the post as solved. I modified the title of the thread because in reality the first issue I had brought up I still could not solve, but you mentioned better solutions.

Thanks again for the answers and suggestions.

In case someone has the same original problem I had with the basic-captcha form field.
I just stumbled upon this issue. Haven’t tested it but I think this post is actually the solution to that original question I posted.