[Carnage]

Well... we /had/ an admin who's in the past been noted for 'accidentilly' deleting users (her excuse was she dropped the keyboard. ) and having a .bash_history file containing meny entries similar to 'el ess'. Also, if you dont understand how cidr ranges work properly it could be fairly easy to set one too large that hits you as well. (part of the reason theres a hard coded limit on how big the cidr range can be)

My only thought about excluding login.php was that if you ip banned someone for trying to brute force login names it woudn't stop them, on the other hand, vb is quite resistant against that anyway with the strikes system and its something you should probably be adding firewall rules to prevent instead of vbulletin ip bans.

If an admin has two accounts, they could just go in and add an exempt from ipbans ( once coded) for their own ip. An alternative was something i was thinking about a while ago - exempting ip bans by user group, which could be done as a setting or as an option (probably the better way)

EDIT: bleh, wont work. Login.php dosn't provide a login form, so another page would have to be provided to do that. I have made it so that admins can now login ( by going to the admincp and logging in from there) and since ip bans arn't verified in the admin cp, they can remove the ban preventing their access.

Unbannable ips is in; still need to test it, but i'm pretty sure the code is sound.

----------------------

Next step is to decide how best to implement exempts; I had two ideas
1) apply bans in decreasing order of cidr range. This would allow, for example you to set a ban against a range of /16 blocking off a troublesome group of spammers. however you could then exempt a group of /24 that are acctually nice people then you could ban an couple of /32 ips that were not quite as nice as you thought they were.

This is much more flexable, but complex.

2) Exempts overide bans.

eg if an exempt is set your ip will be allowed in no matter what.