tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: restrict the number of login tries.
Date Fri, 17 Aug 2001 16:46:44 GMT
It's actually easier than that.  The realm can return:
BaseInterceptor.OK  -- user authenticated.
BaseInterceptor.DECLINED  -- I can't authenticate her, but maybe someone
else can
Other (my personal favorite is 403) -- user can't be authenticated and
nobody else should try.

Thus if the first interceptor returns 403, the user gets whatever is
configured for the Forbidden error page.  At a slight risk, you could also
use a currently un-assigned code and configure the error page for that to
tell the user that the maximum number of tries has been exceeded (if you
feel like being friendly to crackers).

----- Original Message -----
From: "Joseph Toussaint" <>
To: <>
Sent: Thursday, August 16, 2001 8:24 PM
Subject: restrict the number of login tries.

> Hi i'd like to write a module that would restrict the number of times
> someone can login tomcat before their account is locked.  I realize that I
> could modify the realm that I am using - but I'd like to find a more
> solution that could be applied to all security realms without requiring
> users to re-compile.
> Here is what I understand of the security role process
> A controller class gets a list of all the Request Interceptors
> If one of those interceptors is a security realm it calls the authenticate
> method
> if it returns true, it breaks out of the loop - otherwise it moves on to
> the next interceptor.
> Here is my thought on how to do this (although I see a problem with it)
> have 1 interceptor at the top of the request interceptor list (singleton
> pattern)
> have as many security realms as you want
> have 1 interceptor at the end of the list (singleton pattern)
> by the time I get to the last interceptor I know that all previous realms
> have failed - so I know this user has failed, I bump the counter.
> the first interceptor asks the last interceptor if this user still has
> tries left - if they do return false, so the security realms will try to
> authenticate the user.
> the problem comes when the user is out of 'tries'  the first interceptor
> returns false, but the controller still asks the other interceptors to
> authenticate the user.
> I have 2 ideas on how to solve this problem.
> 1. maybe if I set the username to null - it will flag something in the
> controller class and, so it won't ask the other realms to authenticate
> user.
> 2. throw an exception.
> I'm not a big fan of runtime exceptions, so I'd prefer something along the
> lines of #1
> I appreciate any suggestions, or even a new design!
> thanks!
> joe

View raw message