Timin out from a bean

[Christopher Sharp]

Hello,

I want my session to timeout after a given interval of time. In web.xml I've been playing around with:

<session-config>
  <session-timeout>20</session-timeout>
</session-config> 

where the time is in minutes. This works correctly for testing if I set the time to 1 minute

What I would like to do is to do it programatically using code like this inside my bean as follow:

@ManagedBean(name="login")
@SessionScoped
public class MyLoginBean implements HttpSessionListener, Serializable {

// private variables etc.

	HttpServletRequest request;
	HttpSession session  = request.getSession();

	public MyLoginBean() {
		session.setMaxInactiveInterval(20);
	}

// The rest of the code

}

where the timeout here is now 20 seconds for test puposes. Unfortunately, on opening up a browser to look at the application, it fails with the message:

com.sun.faces.mgbean.ManagedBeanCreationException: Cant instantiate class: com.csharp.MyLoginBean.

Followed by:

java.lang.NullPointerException

What am I doing wrong here? I know that setMaxInactiveInterval() refers to the particular session, which in this case is the login bean, rather than everything, which is what the code in web.xml specifies. I have several beans, but timing out the login bean is the only one that matters.

I'm using JSF 2.0 with Glassfish 3.1.1 and Eclipse Indigo, so some advice would be very much appreciated.

[Tim Holloway]

Even before we start talking JSF, there are a couple of things.

1. User-designed login systems are one of the biggest causes of exploitable webapps there are. I always recommend using a security system that was designed and tested by professional security experts over the DIY approach. J2EE has a login system built right into the specification and it's quite adequate for the overwhelming majority of all J2EE webapps. I realize that almost every J2EE book ever published has a sample "login form" processor, but in the real world, that's just painting a target on your back.

2. Web applications are not processes. They do not execute except when a request comes in, needs processing, and a response is sent. They do not run as tasks or threads, but instead are called on-demand under a thread that is assigned by the webapp server when the request comes in. That thread is then returned to a general pool when the response has been sent back. So JSF bean or not, there's no way to set up a timer in J2EE-compliant code.

3. The J2EE HttpSession object has a finite lifespan, which can be specified in the WEB-INF/web.xml file. The lifespan is the maximum amount of time allowable between incoming Http requests from the user associated with that session. Thus, every time a request comes in, a countdown begins for the session. If that countdown goes to zero, the session is destroyed by the webapp server (NOT the web application). The actual time of destruction is not predictable except that it is guaranteed not to be destroyed until the session timeout has expired. The actual destruction will be handled by the webapp server when it is convenient, although the session itself will be unavailable to any requests coming in in the mean time - a new session would have to be constructed if those requests needed a session.

Now for the JSF-specific stuff:

A JSF managed bean is intended to be a POJO. Attempting to store HttpRequest, HttpResponse, FacesContext or other request-related objects in static code will fail, since any such object would be meaningful only as long as the request that constructed the bean is being processed. The same is also true for member methods and constructors - none of these objects can safely carry over between requests.

[Christopher Sharp]

Hello Tim,

Yes, I remember you mentioning a while ago about security issues on login pages. Since then I've been working on other parts of my application, which is now mostly finished, and have not done anything with the login page since then until now. In any case while testing I've diasbled the login.

I was playing around and seeing how to get a system to timeout, but I'm aware that the timeout takes place after the last activity. I tried the following with a very short timeout in seconds:

public MyLoginBean() {
    HttpSession session = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(true);
    session.setMaxInactiveInterval(10);
}

and it appears to work.

I've just done a quick Google search, and there are resources available on this. The problem is that I don't have much time, so I need to put something together that I can get to work without spending weeks on it.

Do you know of any links with canned login software that I can put in my application with the minimum amount of extra work? That would be very helpful.

Incidentally, how do I correct the subject heading? I only noticed my mistake after submitting. Another question is that after clicking "Submit" a CSRF error page appears.

[Tim Holloway]

If you want to set the session timeout interval on a user-by-user basis, I don't think that a JSF bean constructor is the optimal place to do it. You probably should consider putting that login either in a session listener or a servletfilter. That way your session timeout won't be at the mercy of JSF. Besides, there really aren't a whole lot of things it's safe to do in a ManagedBean constructor anyway, since the bean isn't fully initialized at that point.

If you use J2EE Container-Managed security, there are no "canned login" routines, because the login is handled entirely by the server, not by logic in the web application. All you need to do is configure web.xml.

I can't remember where, but if you nose around a bit, you should be able to edit your message heading. The CSRF error is probably because we're working on the Ranch security system at the moment.