Hi guys,
I've experienced an odd session-behaviour of Tomcat 5.0.28.
I'vesetz the overall session-timeout in /conf/web.xml to 1 minute (for
testing-purposes).
We do have a login-form (a jsp), which then calls j_security_check.
When the login-form is displayed, I'm wating for MORE than 1 minute,
and the session times out. I get a message saying "connection reset".
Ok, session's timed out, so I call the url again and enter my
login-data WITHIN this one minute.
No way - I STILL get this weird message, and only if I delete cookies
AND cache, I can proceed with my login-process.
I've tested this behaviour with Firefox, latest build (didn't want to
test it with IE since IE's caching and cookie-handling is an enigma to
me).
Now I've subclassed the FormAuthenticator amd copied the fille
authenticate()-method, and what I can se is the following:
Method FormAuthenticator.authenticate():
// No -- Save this request and redirect to the form login page
if (!loginAction) {
session = getSession(request, true);
// HERE I GET A VALID SESSION-OBJECT, I FIGURE THIS IS CALLED
// WHEN THE FORM-LOGIN-PAGE IS DISPLAYED
saveRequest(request, session);
RequestDispatcher disp =
context.getServletContext().getRequestDispatcher
(config.getLoginPage());
try {
disp.forward(hreq, hres);
response.finishResponse();
} catch (Throwable t) {
}
return (false);
}
[ ....]
// AND LATER ON I'M STUMBLING INTO HERE (AFTER THE SESSION HAS
// TIMED OUT SINCE THE USER HAS WAITED TOO LONG
if (session == null)
session = getSession(request, false);
if (session == null) {
/*
if (debug >=1)
log("User took so long to log on the session expired");
*/
hres.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
sm.getString("authenticator.sessionExpired"));
return (false);
}
So far, so good, makes sense to me, BUT it's really, really od that I
have to delete cookies AND cache (just deleting cookies won't work) to
make a new login possible - otherwise I'm always getting the
"Connection resest"-error-message.
In front we run an Apache http-server 2.something, and the header are
configured to
cache-control:public, must-revalidate
in case of j_security_check or login-form:
cache-control: no-store
Now the big question: Is this a bug, a feature or do I miss something here?
Just imagine the normal office-procedure:
Your client enters the office, calls your site, the cutie from next
door comes in for a chat, he chats his 31 minutes, session is timed
out and this guy is not able to login to your app any more!
Suggestions, please
Cheers
Greg
--
what's puzzlin' you, is the nature of my game
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
