--- On Mon, 1/23/12, Christopher Schultz <ch...@christopherschultz.net> wrote:
> From: Christopher Schultz <ch...@christopherschultz.net>
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Date: Monday, January 23, 2012, 2:42 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To whom it may concern,
>
> On 1/23/12 4:20 PM, removeps-c...@yahoo.com
> wrote:
> > My code does not talk to another cluster as I have a
> single Tomcat
> > only, but just wondering how one would scale.
>
> Me too.
>
> > Maybe the strategy to handle clusters is to write
> information, such
> > as the list of the users to the number of times
> they have logged
> > in in the last hour, into a location shared by all
> machines.
>
> That sounds fairly straightforward.
>
> > In my code below the code is stored in failedAttempts
> which is a
> > Map<String /*username/*, FailedAttempt> where
> FailedAttempt
> > represents the number of times the user has logged in
> in the last
> > hour or whatever. It is in-memory, which is fine for
> one Tomcat.
>
> Right. This is how Tomcat does things in its own
> LockOutRealm. Take a
> look at the code. It works with all realm types (see the
> code for the
> different authenticate() methods it implements).
>
> > But we could move this Map into a file that is on a
> mounted drive
> > available from all Tomcat machines, or we could store
> it in the
> > database. Either way we have to synchronize writes to
> the file or
> > database, and I think database does this
> automatically, and maybe
> > FileLock will do the job for the files. But anyway, it
> sounds
> > complicated.
>
> memcached. Cassandra. Whatever.
>
> > As for my my authenticate it was as follows, although
> I don't see
> > this should cause the failure in the subject of this
> email --
> > "Connection.close() has already been called during
> login":
>
> Yup, it certainly doesn't look like your code does anything
> with the
> superclass's Connection.
>
> > public Principal authenticate(String username, String
> credentials)
> > { threadUserLockedOut.remove();
>
> Why in the world are you using a ThreadLocal in here?
The use of the ThreadLocal is unrelated to the connection timing out. It's
just a variable to indicate that in this thread the user is locked out. It is
used later by my RootFormAuthenticator which extends FormAuthenticator to print
out a message like "Your account has been locked out due to N failed attempts".
FYI
@Override
protected void forwardToErrorPage(Request request, HttpServletResponse
response, LoginConfig loginConfig) throws IOException
{
...
if (realm.isThreadUserLockedOut())
{
message.append("Your account has been locked out due
...
}
else
{
message.append("Sorry, the username or password you supplied is
invalid. Please try again.");
}
realm.clearThreadUserLockedOut();
request.setAttribute("loginErrorMessage", message);
super.forwardToErrorPage(request, response, loginConfig);
}
The actual error page, which is a jsp page, has on it the following HTML
<c:out value="${requestScope.loginErrorMessage}"/>
> It makes me wonder what other odd things you are doing in
> your Realm
> (or anywhere else for that matter).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ
> 5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9
> =Elm7
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
