If you can not find a way to stop a brutal attack from outside the
webapp, the only thing you can do is handle a denied login request as
quickly as possible. Furthermore, a denied login request should leave no
open resources. Invalidating the session immediately would help but I am
not sure this is easy to do unless you use stateless pages from Wicket 2.
Its kind of weird that handling a login request that will be denied
should be handled more quickly then a request that will be granted :)
Because large groups of people can be behind a single ip address you
should be careful with throttling the number of requests per ip address.
I am not saying it is a bad idea, its just that you should be careful to
not overdo it.
I am interested in what you come up with.
Regards,
Erik.
Johannes Fahrenkrug schreef:
> That is true. But how can I let the server software handle this if I
> want specific behavior only with a certain page of the web application?
> Or are you suggesting to let the server software handle all the flooding
> for all the pages of the webapplication (i.e. restricting how many
> requests are processed/handles per second) and to let the webapplication
> handle the specific case of false logins, not caring about how many
> REQUESTS came in, just how many false ATTEMPTS came in?
>
> That sounds like it would make a lot of sense....
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
