4 Replies Latest reply on Oct 27, 2005 12:22 PM by rharrington

    Why Tomcat Session Timeout for JBossSX?

    mrks

      Short question: Why does the Tomcat session timeout impose an effect on JBossSX?

      Long question: Leaving our webapp's login page (presented upon request for restricted content) open prevents the user from logging in after a period of time. As tested, this timespan is set via (Tomcat's) session timeout variable in the web.xml.

      Why so? Does JBossSX rely on a HttpSession to remember the requested URL (restriced content)? This does not appear appropriate to me. (I have to admit, though, we're using JBoss 3.0.26).

      We have to use short timeouts (3 and 5 minutes), as the application runs on public information terminals. My current workaround includes setting session timeouts via code using session.setMaxInactiveInterval(int time_secs) and leaving web.xml's timeout at a fairly high value.

      I am concerned about possible security issues in my workaround. Also, a "clean" solution would be highly appreciated. Thanks!

        • 1. Re: Why Tomcat Session Timeout for JBossSX?
          starksm64

          There is no 3.0.26 version, and the 3.0.x line was based on jetty which we no longer support or use. The question is not entirely clear, so if it can be reformulated in the context of behavior seen in more recent versions we might be able to help.

          • 2. Re: Why Tomcat Session Timeout for JBossSX?
            mrks

            Thank you for your reply, Scott.

            First off, the version we use is 3.2.6. I apologize for the mis-spelling.

            To further descibe the behavior I did a few more tests.

            What happens when you request the login page seems to be the following.

            1.) User requests restriced content off the webapp
            2.) JBossSX interferes,
            3.) Saves the user's requested URL and associates it to the (tomcat) cookie
            4.) Replies with the login page

            When you directly login, everything goes as expected

            5.) User transmits password and username
            6.) JBossSX validates (LoginMolule) successfully
            7.) The user's requested URL is found in whatever store
            8.) The restricted page is presented (after a HttpSession is constructed by the appropriate action class)

            Then you leave the login page open, waiting for several minutes the erroneous behavior is the following:

            5.) User transmits password and username
            6.) JBossSX validates (LoginMolule) successfully
            7.) The user's requested URL cannot be found
            8.) An execption is thrown
            (illegal direct reference to ... [servelt that does login page processing])

            As tested, the time to generate this behavior is controlled by the tomcat session timeout stated in the web.xml. This implies that "whatever store" in step 7 could mean a tomcat HttpSession; one that is immediatly destroyed after login.

            True? Nonsense? I do not know.

            • 3. Re: Why Tomcat Session Timeout for JBossSX?
              starksm64

              This is the expected behavior. You do not have an arbitrarily long period to reply with valid login credentials before the session that was created in the context of the login page is invalidated and you must restart the login process.

              • 4. Re: Why Tomcat Session Timeout for JBossSX?
                rharrington

                I understand why authentication is re-required when the session is invalidated. Makes perfect sense and is the desired behavior for many web-apps.

                I have a need to have authentication credentials persist (ie. to not make users re-login) after a session is invalidated. I have implemented this in a home-grown login module using a cookie, whose expiry date I can (obviously) set. It is currently set to 12 hours which is what our users have requested (its an internal IT app). The result is basically that most users will just need to login in the morning when they get to work, then close and re-open the browser throughout the day without having to deal with the annoyance of logging in every time they open a new browser session.

                I am porting that app to use jboss security via the DatabaseServerLoginModule and it all works great, except for the part where I am kicking users off when the session closes.

                I would think that the need for security credentials to live beyond the session is a sort of common use case. Is there support for doing something like this out of the box in jboss, or is there a generally accepted approach to doing this?

                I was thinking if I had to do it myself I would continue to drop my cookie upon successful access to the app, then on every request, read what the system says the Principal is, and if its null (due to session having been closed) I'd re-set the credentials someway from info in the cookie. I was thinking of using ClientLoginModule for this. Before I start down that road I wanted to check if there was a better or more commonly used/supported approach.

                Thanks!