Right now, this module is rather simple. It has two means to identify and block potential bots.

  1. By the a defined user agent substring - i.e. a self-identified bot
  2. By detecting older browser versions that are unlikely to be used by a real person in this age of automatic updates (for now at least).

I haven't tagged a release for this module yet, because I am envisioning more for this module. What I'd to do is implement additional methods for blocking bots, but then instead of just blocking a request based on meeting a single criteria of many, be a little smart about it, and take an approach used by more genuine WAF tools, and build a risk assessment score, and block based on some threshold. Here is the path.

Define detection methods as a set of Plugins, with corresponding config entities. Each with a definable weighting to the risk score, and their own configurations. Site admins can create their own set of rules, and thresholds based on their own risk tolerance.

So this leads to some additional questions. A big part of the approach of this module is to keep it lightweight, and minimize any database read/writes, to reduce the resources used by serving these bot requests. Does moving to a more Plugin based model like what I described above nullify this effort? Am I simply over-engineering this?

I also want to balance that people are hurting from this new trend of bot traffic right now, and what I describe above will take significantly more time to implement. What is available now may be sufficient to help people tremendously, so that may justify a 1.0 release sooner, than target the above features for 2.0.

More to come...

7/3 Update
1.0.0 Released. I will plan on the more ambitious approach described above for a 2.0 release.

Comments

bburg created an issue. See original summary.

bburg’s picture

Issue summary: View changes
bburg’s picture

Version: » 1.0.0
Issue summary: View changes