Add support for views-exposed-form

Adding this patch here in case someone else can use it. The code is sound, but I'm not convinced this solution is complete.

Not sure this is the job of this module. Should be more relevant to improve form ids for view exposed form no ? And to have, as for node form for example, a base form id (the current one) and a specific form id for the given view. But this is a core issue.

Not sure that's a realistic thing to expect change in Views itself; it would be far too big a breaking change to ever get in.

Moving to needs work since there is a patch. Ultimately the patch is somewhat opinionated here and I am not sure it should be to every view because some views might be programmatically loaded; so I expect its better like a control in Advanced similar to how Views Ajax History has the opt in. This could go into contrib though perhaps extending this module.

Will have a further think myself as I am considering building such (contrib module) given the onslaught of AI scraping bots and their poor ability to navigate forms compared to more established scraping bots like GoogleBot which don't try every combination of every filter (and we don't want to block AI scraping as we want our client's content to appear in AI overviews and be used to help AI's provide better answers overall (our clients are think tanks, their content is important for overall quality of training data).

FYI I created this here https://www.drupal.org/project/protect_views_flood_control → - Feedback very welcome

Thanks for creating Protect Views Flood Control @scott_euser, the more options, the better! The bot onslaught seems to be ramping up, and previously I just banned the most aggressive bot IP's, but the past few weeks the bots are increasing in number, and most interestingly, from a multitude of IP's, making it look a lot like a DDOS-attack, and also making IP-based rules obsolete.

For sites using Facets 3, switching from links to checkboxes may help ( 🐛 [Facets 3] Render using theme input and select instead of lists with links for checkboxes and dropdown Active ) ... still, using a module like Protect Views Flood Control → may help in some scenarios, though it will of course also throttle regular users.

Yeah best could get to was really short window and low frequency (compared to big window/big thresholds applied in most places).

Beyond that was thinking whether an option could be to block filters altogether when ajax enabled and ajax isn't used, allowing pagination only perhaps. Checkboxes hasn't worked, we have been hit anyways from aggressive scraping on views exposed forms even solely having checkboxes instead of links.

In any case it's a sort of fallback to things that get past cloudflare

Thanks for sharing that switching from links to checkboxes hasn't really worked to prevent aggressive scraping, then I won't put all my eggs in that basket. The Ajax method sounds interesting, though that may limit some from using it ...

One thing I have noticed, is that my statistics system Matomo will not register bot visits, it seems mainly by ignoring users without JavaScript, which most bots seem to not execute, thought as they write "... but advanced bots now have the capability." https://matomo.org/faq/new-to-piwik/faq_63/

Still it might work, but the question is how to reliably block users without JavaScript.

Another approach could be using Honeypot checkboxes, where a Views exposed form could be stuffed with extra checkboxes hidden for regular users. As soon as a bot checks a Honeypot checkbox: "Bam, Banned!"

That's an interesting suggestion with the honeypot!

In https://capellic.com/blog/ai-bot-abuse-our-evolving-strategy-taming-perf... @smustgrave just posted he goes into details on what worked for them.

For honeypot I wonder if it's accessibility issue having extra hidden form field if its not then hidden from screen readers (in order to not be hidden from AI bots)

Fantastic article by @smustgrave, I somehow missed it on Planet Drupal, so thanks for sharing it! I added a link to it in the Forum post, and added it to the Bad Bots doc page → as well.

I will totally use the article as a blueprint for my future strategies. I do note that @smustgrave seems to believe that switching from facets as links to checkboxes has made a difference ... I am encouraged by that observation.

About the Honeypot approach, you're right that there could be accessibility issues having hidden form fields, but then won't the Honeypot → module have that problem? I created ✨ Honeypot Facets 3 submodule? Active , let's see if it's possible :)