Add the friendlycaptcha module

The MR !116 suggests the replacement of antibot and honeypot with friendlycaptcha.

The test fails as it runs a test that doesn't exist in the issue fork, I'm not sure where this is coming from.

Seems like the possibility to run it completely locally is a big plus. We have also used https://www.drupal.org/project/hcaptcha → , but I do not think it can be run just locally (do we need to evaluate more captcha modules?).

Other question is, do we need to remove Honeypot and Antibot? We use combination of reCaptcha, Honeypot and Antibot on a lot of sites and efficiency has alway been better when we used more than one module for a bot protection (though not sure about the FriendlyCaptcha efficiency, because we have not used it).

@jurgenhaas I think this call should be made by the contact form track. Have you discussed it with them?

@pameeela I haven't yet, but the form protection goes beyond contact form and into base product as it also protects the login, password reset and registration form by default.

True but we don't want two totally different strategies!

Sure, contact form requires the antispam recipe and would therefore automatically get what's being proposed here automatically. I've left a note about that in the other issue as well.

I've rebased the MR so that it can be reviewed again.

A few things:

• Tests are not passing yet
• There are some things in the recipe that are incorrect
• We need explicit functional test coverage of this, just to prove that all the forms we enable a CAPTCHA on, actually have a CAPTCHA appear. We don't need to fill out the CAPTCHA or test that it works - just that it appears where we configured it.

We probably need to add something like this $this->config('captcha.captcha_point.user_login_form')->set('status', 0)->save(); to InteractiveInstallTest::testPostInstallState(), just before the login attempt, as the recipe is turning on the protection of the login form.

I agree with @jurgenhaas that this is most likely a base recipe feature, not a feature of the contact form. It is important to have at least forgotten password and registration forms protected as well, which is not what I would expect from the contact form track.

Other than that, I still think that we do not need to remove the honeypot and antibot together with this new addition. Why do not we just add friendlycaptcha?

Thanks!

The registration form is disabled by default. I have never heard of needing bot protection for the forgot password form, is this something others have had issues with?

In order to apply it as part of the base recipe, I think it needs to be protecting at least one form. So for now, I think a dependency of the contact form recipe is sufficient. User registration is not a common feature for our target use cases, but we could have a recipe that enables it and depends on the anti-spam recipe.

The registration form is disabled by default. I have never heard of needing bot protection for the forgot password form, is this something others have had issues with?

We usually add it to forgot password forms as well, but mostly in cases when the user registration is turned on, or there is a commerce store or other ways to register accounts. The reason is that a bot can create an account with a fake email address (even if there is an antispam protection) and then the bot can use the forgot password form to spam that email address (which belongs to the account) asking for activation/password reset links. It is not a 100% full protection, only a hardening, but when "fighting" with bots, even small things count. On the other hand, we typically do not use these protections on login forms.

The registration form is disabled by default.
...
In order to apply it as part of the base recipe, I think it needs to be protecting at least one form.

I didn't know that the registration will be disabled. So yes, this seems reasonable to enable it only in case there will be something to protect.

I wonder where the drupal_cms_antispam recipe is heading to. If that stays as a separate recipe, friendlycaptcha should be added as a third tool next to antibot and honeypot. If the antispam recipe goes into the base recipe or elsewhere, this should go with it.

And then all 3 tools should protect all public facing forms.

Once we've decided which direction to take, I'm happy to get back on it and do the necessary work.

@phenaproxima I've sorted your comments in the MR. Now wondering if we I should bring back the antibot and honeypot into the MR as the current approach was to replace them, but it rather looks like we should add the additional module instead.

🤔 That decision, I think, lies with the product owner. So, assigning to @pameeela for consideration.

Once we have that decision, we need to fix the tests before I can merge this.

I'm thinking that anti-spam should remain its own recipe so that it can be independently used by drupal_cms_forms and the forthcoming drupal_cms_authentication recipe as needed.

I'm thinking that anti-spam should remain its own recipe

Yes, agreed. I don't think it needs to be in the starter, it should only be applied by other recipes that require it.

But I am not totally sold on having all three added at once. Antibot and Honeypot are invisible to the user. Captcha is not. Potentially we would split these out and enable the baseline of Antibot and Honeypot if you opt in to specific forms, and optionally Captcha on top of that if you need it? Sort of like basic SEO and advanced.

Open to input on this but in my experience, it is not common to have Captcha on by default when you add a form to your website. I agree it's valuable as an option but I don't feel it's the baseline. I personally try to avoid it if possible and go with the non-intrusive options first, and if that's not working, resort to Captcha.

Don't get me wrong, I'm not feeling strong about this. I'm just talking from our experience that if a domain gets on the agenda of spammers, the antibot and honeypot tools have no great effect any longer. We saw this happening with our customer's sites, the bot learned to circumvent them. The support channel in Slack demonstrates that regularly as well.

The friendlycaptcha is effective in those scenarios, but it's not a captcha as typically known where the user needs to resolve a puzzle. The only thing the user needs to do is to click on the widget. And here, we're seeing no spam at all and we don't receive any reports about false positives.

Still, if we don't want to introduce that to Drupal CMS, I'm ok with that. My recommendation would be to go with it, though.

One possibility here is to add the module, but only "activate" it (e.g., add a CAPTCHA point) on the forms that are most likely to be spam magnets, like the contact form, which are also the most likely places where users will expect to see a CAPTCHA.

I kind of agree with @jurgenhaas that if your site is suddenly being targeted by spam bots and the existing anti-spam tools are ineffective, then you as a non-technical user might have a hard time figuring out how to set up a CAPTCHA. This would all reflect poorly on Drupal CMS. So I generally favor stronger anti-spam measures out of the gate, without being too intrusive (i.e., we don't want content editors to have to do a CAPTCHA every time they log in).

you as a non-technical user might have a hard time figuring out how to set up a CAPTCHA

That's what recipes are for! I am proposing that captcha could be a separate, optional recipe instead of part of this one.

Oh, interesting. I think I could get on board with that. Though honestly? It might make sense for that recipe to live in the Friendly CAPTCHA module. It's an emerging pattern for modules to provide a recipe or two that set themselves up in useful ways, and this might be a great choice for that.

It might make sense for that recipe to live in the Friendly CAPTCHA module.

That wouldn't be necessary, as it would just be the module to be installed with its default setting - assuming that the recipe in the module wouldn't introduce a different default setting from the module itself.

Giving it exposure for Drupal CMS, turning this into a recipe of its own so that the user could choose "Enhanced Spam Protection" on the installation screen, might be a good way forward. Or just ship it with Drupal CMS and let them discover it in the project browser when they need it.

Yeah, I think that 'Enhanced spam protection' as a recipe is the way forward. The thing to keep in mind is that the site is initially under development for some period of time; not everything has to be ON right away. Captcha/extra spam protection is something we can cover in the user guide too as well as in a 'get ready for launch' checklist type of thing.

OK, so I'll adjust the MR in a way that it is separate from the anti-spam recipe and can be enabled later on. The only form to be protected should then be the comment form, I guess. Right?

Moved this into a separate recipe and restored the original anti-spam recipe. The failing e2e test doesn't seem to be related here.

Let me know if this needs any further changes.

I actually think it might make sense to not have this be its own recipe from the start, but rather merge it into the forthcoming 📌 Blog - Set up an MVP for a blog comments recipe Active , where it would be immediately useful...and then split it out later if it will be needed in other contexts.

Part of my reasoning is that blog comments seem like a much more "no-brainer" spot to have a CAPTCHA by default, and I also don't love the "agony of choice" factor of having both a basic anti-spam recipe and an "enhanced" anti-spam recipe -- to someone who doesn't know much about the difference between the two, it would feel like a nebulous choice.

The final call on whether this should be its own recipe, or packaged with blog comments for now, should probably be Pam's decision. Assigning this to her, for that reason.

I don't think this should be part of the blog comment recipe. Most sites will not have blog comments turned on, but many will have contact forms, and they may want the extra protection. I see captcha as a standalone feature that sites may want to add.

I also don't love the "agony of choice" factor of having both a basic anti-spam recipe and an "enhanced" anti-spam recipe

Where does the choice come in? The basic recipe is applied by default. So it's just a question of whether you want captcha? I also think we are better off just calling it 'Captcha' than 'Enhanced spam protection' since that's more clear.

I looked at Friendly CAPTCHA a bit more closely and discovered that there is a major technical roadblock that fully blocks us from adopting it right now. It's right there on the module page:

Require the module, e.g. via composer: "composer require drupal/friendlycaptcha"
Get the library file here
Put the file inside "/libraries/friendly-challenge/"

That's right: it's our old friend, the frontend libraries problem. The fact that there is no way to do this with core tooling means we cannot adopt this module. Relying on Asset Packagist is not an acceptable workaround, unfortunately.

I think the best path here would be to do what Webform does, and change the module to default to serving the necessary library from a CDN, with the option to use a local copy if available. But until Friendly CAPTCHA supports that, I don't think we can add it to Drupal CMS. So I'm postponing this issue indefinitely.

The library issue is resolved and part of the recipe I provided. There is no extra requirement needed, that's just not documented on the module page yet.

Ah, well - I didn't know that! Let's un-freeze this issue, then.

I've closed ✨ Add optional CAPTCHA support to the contact form recipe Active in favor of this one, but let's transfer the approach from there into here:

• Let's do all this in the drupal_cms_anti_spam and drupal_cms_forms recipe, rather than adding a new one.
• We'll add Friendly CAPTCHA, but not install it.
• We'll add a CAPTCHA element to the contact form and test that it is, by default, not visible; but if you go and install the Friendly CAPTCHA module, it becomes visible right away.

This gets us the best of all worlds - CAPTCHA capabilities exist, but are latent.

Self-assigning to implement.

OK - this seems to work as expected, and has an end-to-end test to prove it.

Ultimately, it has the anti-spam recipe install and configure Friendly CAPTCHA, but the drupal_cms_forms recipe actually opts into using it (if the user decides to do so, which they can do with a boolean input value).

Assigning to Pam for manual testing and sign-off. Run ddev apply-recipe recipes/drupal_cms_forms to apply the recipe, which will ask you if you want to use the CAPTCHA (defaults to no).

Cool! I like this also because it's a handy user input example for recipes.

I agree - this is a solid improvement. Merged into 0.x.

Automatically closed - issue fixed for 2 weeks with no activity.