submission and re-present the login
page. As you say it's not ideal and better to avoid as many instances as
possible.
HTH,
Jon
-- Forwarded message --
From: David Smith <[EMAIL PROTECTED]>
To: Tomcat Users List
Date: Thu, 19 Oct 2006 08:45:06 -0400
Subject: Re: logi
Jon (and Mike),
> But you need to cater for the people who hit the login page and then go
> to lunch. Happens more frequently than you might think ;)
I recently switched to securityfilter. It's pretty much a drop-in
replacement for Tomcat's authenticator, and does not suffer from the
problem that
IMHO, a custom 408 error page is in order for abandon login pages. Or
possibly a meta refresh in the login page that pushes the client back to
the public page after 10 minutes.
--David
Jon Wingfield wrote:
But you need to cater for the people who hit the login page and then
go to lunch. Ha
But you need to cater for the people who hit the login page and then go
to lunch. Happens more frequently than you might think ;)
David Smith wrote:
Don't send people who logout to a protected page, forcing a login page
to appear. Better to offer up a public, non-login page and have people
cl
Don't send people who logout to a protected page, forcing a login page
to appear. Better to offer up a public, non-login page and have people
click a link to initiate a new request for a protected page.
--David
Michael Swierczek wrote:
I'm receiving a 408 error, and I do understand why. I
Quick and dirty solution is to have your login page make a meta refresh
every, say, ten minutes pointing to the index page of your protected
content.
This simple approach works for us. We also catch "unexpected" errors
coming back from the login form submission and re-present the login
page.
I'm receiving a 408 error, and I do understand why. I just can't
figure out an end-user friendly way to avoid it.
The application runs on Tomcat 5.0.28 with form-based authentication.
It is accessed by some end users from regular PCs, but most connect
from kiosk web browsers. When someone init
