If he does it again, I actually would let it happen, but I suggest you create a backup first of your forum asap. That way you can restore the backup and have the proof of him doing it. After that, I would turn off the forums until you guys can stop him from doing it.
nice plan. I'll start a backup now.
But his attacks aren't too frequent and it only results in about 45mins of downtime so I'd rather leave the boards open.
Are the posts separated by seconds/minutes, or are they separated by less than a second?
I honestly can't tell you, I deleted them all.
but there were ~7000 posts in ~30mins posted by 10 accounts (more were made, just not used)
They were withing seconds, by seperate accounts. So account A posts then account B posts a second after that one, C a second after B, etc.
There has been a report that a script rapidly making POST requests to the posting scripts may be able to bypass the flood prevention system (the POSTs have to be made very rapidly in succession), so that could be the problem. For 1.4, Tikitiki's already tried to optimize as much as possible, the time between a post is made, and the time that the time of the post is recorded.
Could you not record the post before it is actually made?
and I think this was bought up on page 1
oh and for anyone that cares, that damn image is back on his server.
I've also sent him an email, with his WHOIS information and a message stating he should cease.
There's a small amount time time (milliseconds) in which it takes to start script x and get to the checking for script x, resulting in a time gap in which you can put in multiple posts bypassing the checking.
hm, would this work:
User presses the post button.
A record is added to the database with a timestamp(or something) and a userid.
check that it is the only record in the db (in case another has been made at the same time)
The post is parsed and added to the database.
check that it is still the only record in the db if it's not delete the post just made.
The record created above is removed.
If the user tries to post whilst that record is in place they receive a message saying they're posting too quickly
viable?
Thats not the problem though. We already do that. But as I've explained in my post above it can be circumvented with the use of a very fast script or a slow server.
We've already optimized it as much as possible to prevent this in the next version.