Honeypot functionality is not working

[ajoliveau]

Description

GravityForms allow admins to enable Honeypots on forms. What this does is that when it renders a form, it adds a hidden input. When it validates a form submission, if this input has a value, it must have been automatically filled by a bot so the entry is discarded.

When using Graphql and a headless implementation of the form, what I wanted to do is add the hidden input manually to my forms, and sent it to Gravity Forms so it can validate the submission and I have nothing to handle in the backend.

But the way GF handles this honeypot field is that if the honeypot is enabled for the form, it creates a "virtual" field, it's not part of the form main fields like a captcha would be, but GF instead renders a field with its ID being "the highest ID + 1"

So if I have 12 fields, input going from 1 to 12, the honeypot field name for Form 1 would be something like input_1_13

If I try to manually submit a honeypot field value to the submitGfForm mutation, I get an error The form (ID 1) does not contain a field with the field ID 13, even though I'm pretty sure GF would accept this field.

Steps to reproduce

1. Create a form, add one field (id = 1)
2. Enable the Honeypot feature for the form
3. Do this query

   mutation {
   submitGfForm(
   input: {id: 1, fieldValues: [
     {id: 1, value: "text field"},
     {id: 2, value: "honeypot field, GF should discard or flag this entry"}
   ]}
   ) {
   confirmation {
     type
     message
   }
   }
   } 

4. Get an error message from wp-graphq-gravity-forms instead of a success message

Additional context

No response

Plugin Version

0.12.6

Gravity Forms Version

2.7.17

WordPress Version

6.3

WPGraphQL Version

1.14.3

Additional enviornmental details

php8.1

Please confirm that you have searched existing issues in the repo.

• [X] Yes

Please confirm that you have disabled ALL plugins except for Gravity Forms, WPGraphQL, and WPGraphQL for Gravity Forms

• [X] Yes
• [ ] My issue is with a specific 3rd-party plugin.

[justlevine]

Thanks for reporting this @ajoliveau ,

Indeed, it looks like v2.7+ changed the way honeypots are handled in order to support the Create an entry and mark it as spam option (marking as enhancement for future inclusion). That said, I'm not entire sure your specific use case for handling the default Do not create an entry honeypot behavior.

Let me explain:

If I try to manually submit a honeypot field value to the submitGfForm mutation, I get an error The form (ID 1) does not contain a field with the field ID 13, even though I'm pretty sure GF would accept this field.

While this is true in the GF _frontend UX, what actually happens in the code is that the entry fails validation without an error message, and then the frontend just mocks the success. Similarly, if you were using GFAPI or GF's REST API, you'd get an { is_valid: false }, and then it's up to you to decide how to handle that.

In a Headless context, you would ideally prevent the submission from hitting the server altogether if the honeypot field is submitted, and instead mock a success message using gfForm.confirmation the same way the GF frontend UX does it. If you do choose to submit the field and Do not create an entry is the honeypot behavior, you will get some sort of error and handle it yourself.

So, even while an enhancement that recognizes a honeypot field ( in order to support Create an entry and mark it as spam behavior) would change The form (ID 1) does not contain a field with the field ID 13 GraphQLError, you would still need to handle the failure, just deriving it from response.submitGfForm.errors instead. The ideal headless behavior would still be to avoid submitting the field altogether.