Optionally enable CAPTCHAs for every webform automatically

Per https://www.drupal.org/node/3035729 → we should be using the Captcha element instead of points. This is mainly because the form ID changes depending on where the form is used, and we are likely to add it to a node via LB -- so we won't know the form ID.

This approach is also nice because it is quite obvious how it works, since the element is visible in the form builder.

I also want to check with the Contact form track lead on why they didn't include Captcha in their recipe. Should have done that earlier.

I actually tried adding a CAPTCHA by using a Webform element, and it just will not work for a number of technical reasons.

Or, rather - it will work if we add it to the form...but then there's no way to make it optional using a recipe input. This seems to be due to the way Webform is architected. There might be a way out if Webform supported certain config actions, but I'm not holding my breath for that. (Although we could patch Webform to add support for the necessary actions; chances are it would be just one line in a few places.)

My question is why exactly would we attach the form to a node? Is it just for visibility in the /admin/content list?

why exactly would we attach the form to a node?

A few reasons, for one: so we can add content to the page, without having to use a webform element. Having it in the list of nodes is also nice! But I wouldn't do it just for that. Not that it's a huge insight but benchmarking shows that almost no one has a page called Contact with just a form on it. They want to add some text, perhaps their business info etc. And doing that using the form itself just kinda sucks. You also don't get regular alias behaviour, or menu settings.

I get that it's not possible to do this optionally. I do think in that case we can either or enable Captcha by default OR have a separate recipe to enable Captcha; and then a tour for adding it to the form. It's much easier to show a user how to add it to the form than to deal with the Captcha config and endpoints.

I added a config action to the Webform project here https://www.drupal.org/project/webform/issues/3490313#comment-15877907 ✨ Add Config Action to enable captcha form elements Active that will add a `captcha` form element. With this, we'll be able to add the captcha points as a form element.

I have some code to work with that plugin going locally. I'll work on getting it pushed for further testing.

I don't think we should proceed with this as proposed.

Why? Because the MR breaks the optionality of having a CAPTCHA. It will always add a CAPTCHA to every webform. That's not the desired behavior.

I would suggest that we do not use a new config action for this, and instead create CAPTCHA points automatically for every webform, and set their status to what the ${captcha} input specifies. Recipes already have the tools for this; see the createForEachIfNotExists config action from core: https://www.drupal.org/node/3481714 → .

I believe the intent is to move the contact form into a layout builder section of a basic page so that additional content can be included along with the form. Assuming that is the direction, the form id will never be consistent and will always include a node id. Inserting the captcha as a form element instead of a captcha point will allow the captcha to be present without needing to know a node id.

The other option would be to have the captcha point utilize the base form id, which should include all derivatives of the contact form placed in a layout builder section.

I did a quick test of the latter option by adding the base form id `webform_submission_contact_form_form` as a captcha point and placing the contact form in a layout builder section on a node. When browsing that node anonymously, the captcha did show.

So, either of the above options should work. I guess it might come down to editor experience at that point... does it make sense to have a captcha element on each form like any other form field or does it make sense to route an editor to another configuration page to add a captcha point?

Let's go with the second option for now, but I'll seek input from @pameeela about this.

I prefer using the form element, it is the recommended approach and is much more intuitive in my opinion. The editor can clearly see it and remove it if they want, or add it to new forms based on this example.

If that's the preferred approach, then we need to get the necessary config action(s) into a tagged release of Webform. This is very unlikely to happen in time for Drupal CMS v1.0.0. We should probably postpone this issue on ✨ Add Config Action to enable captcha form elements Active .

Only if it's not on by default? But I think the consensus is that it could/should be.

So can we update the form to add this, and worry about making it optional later?

I updated the MR with this, but I'm not able to change the branch to 1.x.

I changed the branch to 1.x. I also changed the status back to needs work to get the build errors addressed.

After rebase there are e2e test fails but the tests just need updating.

I personally have no strong opinion about whether we use a CAPTCHA. The final word on it belongs to you.

I updated the tests to pass without actually getting a successful submission. Not sure how to get Cypress to bypass and/or pass the Captcha element?

Not sure how to get Cypress to bypass and/or pass the Captcha element?

As the purpose of the captcha is to prevent bypass, the user should just that. It should not be possible to submit the form.

In customer projects we also sometimes need to get the form submit. For that we disable the captcha temporarily.

That way we can test both.

rohan_singh → changed the visibility of the branch 3485552-captchas-everywhere to hidden.

I'm happy for this to be merged once the tests are satisfactory, not sure if that is now or not but putting it here either way!

One question, one probable loss of test coverage that should be adjusted instead, and one nitpick. Otherwise this looks good to me!

Also updating the issue summary to reflect the final MR.

I addressed the MR feedback. This is ready to review again.

Thanks @pfrilling. That looks better - but we had a miscommunication (I'm sorry about that!) regarding the test coverage.

I believe I addressed everything. Please review again.

Zero complaints remaining. Nice work. I'll fend off any random failures and merge this as soon as the pipeline is green.

Great work here, thanks for sticking with it through that unexpectedly lengthy review process. Merged into 1.x, thanks!