Topic on Extension talk:AbuseFilter/Rules format

I'm trying to figure out a way to prevent ddosers from editing the same page one million times on my wiki (This can be done by using bots mind you), but none of the functions here seem to work.

The closest to what I want is Timestamp which checks the current time, however it is the current time of the wiki, not the time of the last edit on any given article. I did not realize it immediately, so I wrote this timestamp <= (timestamp+10)thinking this would stop the spambots from editing causing issues to my wiki, but it flagged all the edits made by other users.

I eventually opted to prevent editing from my wiki, unless you register your email address until I get this covered.

What I need does not seem to exist on this list, so it would be great to have a function like last_edit to check when was the last edit made on an article.

Before you tell me to just "ban them", keep in mind spammers can just register another account and evade IP bans through VPNs, just help me fix my issue instead of gossiping.

You can probably use a abusefilter throttle for this. Simply check for any edit to a specific page or group of pages, perhaps for new or non-confirmed users only, and then set the throttle limit to, say, one edit per day, with a disallow action. In other words, let the throttle handle the time tracking. Depending on your problem you could also group the throttle by page or by user. ~~~~

Use Manual:$wgRateLimits for that.

AbuseFilter would need a timestamp of the last (current) edit on that page, which doesn't exist as a variable, but you may request it if not requested already.

As mentioned by Zzuuzz above, the canonical solution here is using throttling. You'll want your filter pattern to just check the specs of the current edit, e.g. !("confirmed" in user_groups), and then configure the throttle action to allow say one edit on the same page every x minutes, and add "disallow" or "block" as additional action. Also, note that timestamp <= (timestamp+10) is a tautology, regardless of the language we're talking about.

You can also propose the implementation of a new variable, but I'd like to see concrete use cases before implementing new variables.

Finally, I do think that using $wgRateLimit as a safety net is really a good idea, regardless of spammers and filters.

HTH!