I know this may screw up some considerations you may have such as not to duplicate actual code from the core, but I think it would be beneficial to check whether the IP is banned before checking everything else in Protector.

I say this because as it is now, when a DOS attack does come in, the precheck code in Protector performs several queries, 1 query to get Get Protector preferences and 4-5 queries in check_dos_attack_prepare()

Not only does that mean that on each page load, even a banned IP will still perform 5-6 queries, it will also be REGISTERED every time, resulting in those 30+ pages of logs with many recurring IPs that has become common on xoops.org

This is not an entirely simple task, because it means that you will have to retrieve a system preference (or two, actually - 'enable_badips' and 'bad_ips') before the XOOPS core API has been included... but perhaps you could have a Protector-specific list of banned IPs and a on/off setting (or just the list) so it is fetched in your call to get Protector preferences in the first place... just an idea.

Keep up the good work

Hi Mithrandir.

I also found "IP ban" issue on last sunday.
Many DoS attacks were done that day, and my server was forced to hang.

My idea to resolving this issue is that calling check_dos_attack_prepare()
method from postcheck.inc.php instead of precheck.inc.php.

How do you think?

----------
In Japanese.
----------
check_dos_attack_prepare() の呼出を、precheck.inc.phpからpostcheck.inc.phpに移して、
先にcommon.php内でIP拒否をさせた方が良いのでは？
ってアイデアなんですが、いかがでしょうか？

hi Mithrandir & nobunobu.

I'm sorry that my answer is too late.

I've just understood what you mean.

It is just a historical reason.
(2.2 does not have postcheck.inc.php)

I also think that the time has come the queries should be moved after common.php.

My conclusion is this:

If DoS has come, "IP ban" is almost useless in XOOPS level.

It should be added into .htaccess as "DENY FROM".

After this, DoS attack can make no damages.