tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hayo Schmidt <>
Subject Re: How do i handle session-timeout in an acceptable manner?
Date Thu, 02 Oct 2003 08:36:24 GMT
The problem with your solution is, that the application does not know 
where to continue after the login page. This will result in an error.

I have implemented this workaround:

    protected void doGet(
        HttpServletRequest httpServletRequest,
        HttpServletResponse httpServletResponse)
        throws ServletException, IOException {

        String reqURI = httpServletRequest.getRequestURI();
        if ((reqURI.indexOf("/actions/") != -1)) {
            // Calling of 'actions' via get is not allowed
            String referer = httpServletRequest.getHeader("referer");
            if ((referer != null) && (referer.endsWith("/loginpage.jsp))) {
                // if this happens, we probably had a Time-Out
                RequestDispatcher dispatcher = 
                dispatcher.forward(httpServletRequest, httpServletResponse);
            } else {
                throw new ServletException("Action forbidden.");
        } else {
             // Call shared, standard request processing code.
            processRequest(httpServletRequest, httpServletResponse);

What it does: if there is a get call to an URL that should be called as 
post, and the referer is the login page, then forward the request to 
some kind of informational message.

Of course there can't be any guarantee this works with coming versions 
of Tomcat. So i would like to have an general solution.

Hayo Schmidt


Shapira, Yoav wrote:

>Here's an idea: add an HTML META refresh tag to each page whose redirect
>URL is the login page and whose timeout is the session timeout less a
>few seconds.  That way the user will get redirected to the login page
>before the session timeout -- they won't be able to press the submit
>Yoav Shapira
>Millennium ChemInformatics
>>-----Original Message-----
>>From: Hayo Schmidt []
>>Sent: Wednesday, October 01, 2003 11:16 AM
>>To: Tomcat Users List
>>Subject: How do i handle session-timeout in an acceptable manner?
>>I have a built a web application on Tomcat 4.1.18. The application is
>>running with a HTTPS connection. session-timeout is configured and
>>so far. But i am absolutely not satisfied with what happens when a
>>timeout occurs.
>>The web application is configured for form based authentication. When
>>the connection has timed out, the user is presented the login page when
>>he does his next action. And, all data saved with the session are lost.
>>Fine -  i could live with that.
>>But what happens in a real case:
>>- The user waits too long - timeout.
>>- The user pushes an INPUT type="submit" and creates a POST operation.
>>- Tomcat redirects to the login page.
>>- The user logs in.
>>- Tomcat redirects to the original aim of the post operation, but he
>>does it as a GET operation.
>>Alternative 1:
>>- My application does not allow get operations at this place ==>
>>Application Error.
>>Alternative 2:
>>- The application allows the vulnerable get operation, but the button
>>that was pushed is not passed anymore ==> Application Error.
>>Now what can i do? I must interfere the session timeout to do an
>>operation. Or i should be able to detemine that the current request is
>>the first after a timeout. The way my application currently crashes is
>>not acceptable.
>>Hayo Schmidt
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged.  This e-mail
is intended only for the individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the sender.  Thank you.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message