Default Session timeout in JSF

[Ravi Choudhary]

Hi Everybody,

I have one login page of JSF application. Once I left login page idle for 30 minutes or more than that, then input login id and password and submit button than getting message:

The website cannont display the page - an HTTP 500 error

.

while i did not configure anywhere timeout in application and I am using web sphere server for deploying the application.


Please help.





Thanks & Regards,
Ravi Kumar

[Bin Smith]

Hello!

It is much more secure to use built-in JavaEE security. Then login page (login.xhtml) in FORM based authentication must include
<form action="j_security_check" method="post">
<input id="j_username" name="j_username" ... />
<input id="j_password" name="j_password" type="password" ... />
</form>
In web.xml set this:

<login-config>
        <auth-method>FORM</auth-method>
        <realm-name>olympicsRealm</realm-name>
        <form-login-config>
            <form-login-page>/login.xhtml</form-login-page>
            <form-error-page>/loginError.xhtml</form-error-page>  //you should design this page. If login failed then it is displayed
        </form-login-config>
</login-config>

If you use your own login form then it is almost definitely not secure at all!!!
To set up timeout in glassfish I use this in web.xml:

<session-config>
        <session-timeout>
            30
        </session-timeout>
        <cookie-config>
            <name>SESSIONID</name>
        </cookie-config>
    </session-config>

[Ravi Choudhary]

Thanks Levytskyi for your quick response.


But this will not solve my problem, actually this is happening on each of the action of that page ( i.e New Regisgration , forgot password etc) so I am looking any thing where i can disable/enable session out in application.

[Tim Holloway]

A "500" Response code is not a session timeout. It's an indicator that the application logic threw an Exception. Check your server logs.

Volodymyr is just passing on the advice I gave him. I've worked with J2EE since before they named it J2EE and seen more user-defined logins than I can count, many in critical business functions. And every last bloody one of them had security holes! Usually, in fact, non-technical people could crack the app in under 15 minutes.

J2EE defines a security standard. It was designed by full-time trained security experts, not as an afterthought by someone whose primary responsibilities were something else. It is already present in the server, fully debugged and operational and I've never heard of an instance of it being defeated. It also requires considerably less coding that user-defined security systems, plus the J2EE API defines standard methods to use it. That's why I recommend it.