(response at bottom)
Michael Swierczek wrote:
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 initially connects, a new
session is generated, they see the login page, they enter their
credentials, and login is fine. Then they log out, and the login
page sits with no activity for hours, days, or weeks. The next user
comes along, enters their credentials, and submits. The request
reaches the server with an expired session id and a 408 error is
generated.
I've read parts of the 2.4 servlet specification, and I realize this
is the expected behavior. But obviously this isn't what we want, it
is annoying to end users (even if I hide the 408 error and
transparently redirect back to the login page).
I've never used Ajax, but I imagine it would be possible to
transparently retrieve a new session ID from the server as soon as the
user starts to type a username or password. Assuming I can do that,
it would solve the problem - but I am almost positive other solutions
to this existed before the advent of Ajax.
I would really appreciate any help, or suggestions as to where to
search for more information.
Thanks,
Mike
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------- Forwarded message ----------
From: Jon Wingfield <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Date: Thu, 19 Oct 2006 13:29:40 +0100
Subject: Re: login page behavior and the 2.4 specification
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. 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 <users@tomcat.apache.org>
Date: Thu, 19 Oct 2006 08:45:06 -0400
Subject: Re: login page behavior and the 2.4 specification
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
---------- Forwarded message ----------
From: Jon Wingfield <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Date: Thu, 19 Oct 2006 14:00:23 +0100
Subject: Re: login page behavior and the 2.4 specification
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
click a link to initiate a new request for a protected page.
--David
---------- Forwarded message ----------
From: David Smith <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Date: Thu, 19 Oct 2006 08:58:47 -0400
Subject: Re: login page behavior and the 2.4 specification
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. 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 click a link to initiate a new request for a protected page.
--David
---------- Forwarded message ----------
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Date: Thu, 19 Oct 2006 09:54:33 -0400
Subject: Re: login page behavior and the 2.4 specification
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 you can't login unless you've attempted to access a
protected resource.
http://securityfilter.sourceforge.net
-chris
-------------------------------------------
Gentlemen,
Thanks for the speedy response. I could force the users to start
from a page outside the protected area, but that's one extra start
page which exists for no real purpose save to be clicked through
before the login.
So instead, I borrowed the sample code from this page:
http://developer.mozilla.org/en/docs/AJAX:Getting_Started
and modified it.
When the page loads, a Javascript Date object is created. When
keyboard input is detected, the difference between the current time
and the object is checked. If it exceeds 10 minutes, the Javascript
retrieves (and discards) a new copy of the login page from the server
in order to get a new session id, and of course updates the date
object to the current time.
It's ugly, but my testing looks good so far. The code is really
simple, if anyone wants it send me an individual email.
-Mike
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
