...
Maybe obvious, but exponential backoff in addition to whatever screening you do could probably weed out bots vs humans actually fat-fingering as efficiently without requiring manual switching or locking the fathands out. There's also an nginx module to rate limit by filter if you want to avoid putting it on your backend. People should be using password management systems these days though...
edit: ah yea as @dracora suggested, fail2ban++
Well I only switch the "zero tolerance" on when needed (though it's still on coz there's still a couple of new IP addresses added every minute that get banned immediately Maybe obvious, but exponential backoff in addition to whatever screening you do could probably weed out bots vs humans actually fat-fingering as efficiently without requiring manual switching or locking the fathands out. There's also an nginx module to rate limit by filter if you want to avoid putting it on your backend. People should be using password management systems these days though...
edit: ah yea as @dracora suggested, fail2ban++
The web server is simply a web server.
My KanoDB/Code decides all the rules.
There are no known/expected exploits in the web site, it's all to do with logins.
People try "known exploits" regularly and none have ever succeeded, due to the fact that all the code is my own code, not some humongous dump of code written by dozens of people, each trying to outperform every other dump of common code that people use and thus adding all sorts of risks and problems into the mix.
There's no offsite scripts to open up all the easy to exploit problems they cause, there's not even any CSS from offsite - it's also actually inline to reduce I/O.
The event/ovent code is all in that public git run by that god-complex guy, if you are curious about it's design - but it's controlled by settings that are more lenient than the default in code settings that would shut down the web site all the time
