Bear Bibeault wrote:Are you talking about before or after the session has timed out?
it is after session has time-out.
ok i get your point for using the filter. but how a filter get notified that session is timed out ?
should i keep track of time when was session created and after counting 2 minutes(if session time-out period is 2 min) , a user is notified.
counting of 2 min would be done by Date object.
one more thing that
when a session is time out , the session is still a valid session until session is destroyed. Isn't that it?
Bear Bibeault wrote:I always handle such situations with a filter. Why goop up multiple pages or controllers with code that needs to cross-cut across all (or most) requests?
Let us suppose user is successfully logged in and idle for session timeout let us suppose(20mins). So after 20 mins we should display the alert message and explicitly we should call the logout action. To identify session time out we can take the help of java script whenever the page is loaded it start's counting till 20mins and logic follows. But if we are doing that in filter until and unless the user action we can't identify whether that is valid session or not. Please correct me if i'm wrong.
ocjp 6 — Feeding a person with food is a great thing in this world. Feeding the same person by transferring the knowledge is far more better thing. The reason is the amount of satisfaction which we get through food is of only one minute or two. But the satisfaction which we can get through the knowledge is of life long.
naveen yadav wrote:
it means that when session has been timed out , session is no longer valid and current session object will return null. Is that it?
i am asking this because i little confused about when a session become invalid. Does session becomes invalid when session is time-out or when session is destroyed ?
The session is destroyed either upon timeout or when session.invalidate() is called by your code. Again, look at the HttpSessionListener.sessionDestroyed() method. It will notify you when the session is about to be invalidated.
Mohan Rao Sv wrote:But if we are doing that in filter until and unless the user action we can't identify whether that is valid session or not.
To monitor logged in status, you shouldn't be checking for session validity at all. You should be placing a scoped variable into the session upon login, and removing it upon logout. If the session times out, the variable automatically disappears. Checking for the existence of the variable in the filter, lets you know if the user needs to log in or not.
It's very easy actually. People seem to make it overcomplicated by thinking that they have to check the state of the session itself and get notified when it times out.
once a session is created , from here on , each request must be checked if session is still valid or not using the Filter.
But originally i was thinking to use the HttpSessionListener interface method sessionDestroyed(). because when session time out this method gets notification
But since HttpRequest object is not available , i cant redirect the user to some a page which displays session time -out message.
Correct. That's because the session invalidation usually doesn't happen during an HTTP request but in the background by the servlet container. Just do what Bear suggested, use some session attribute. If the session is invalidated this attribute is dropped, and during the next action the user initiates your application will notice this attribute is no longer present and do whatever is needed.
I definitely wouldn't want a real-time session invalidation to do anything to my current browser contents. Imagine I log in, start reading a long piece of text, and after a while, while I'm still reading, all of a sudden my browser navigates to this error message page because the session is invalidated. That would be the last time I visited your site.
one more thing. should the session attributes be removed explicity?
when a application decides to kill the session for whatever reason (log-out or time-out), and session object no longer exits which makes that all session attributes also does not exists.
Should we care to remove them explicitly ?
Rob Spoor wrote:I definitely wouldn't want a real-time session invalidation to do anything to my current browser contents. Imagine I log in, start reading a long piece of text, and after a while, while I'm still reading, all of a sudden my browser navigates to this error message page because the session is invalidated. That would be the last time I visited your site.
Saurabh Pillai wrote:But it would definitely fail if website is open across multiple tabs.
Joined: Sep 12, 2008
Bear Bibeault wrote: But I've never even seen a site do this.
What if a user does it. When I go to my banking site, I like to open my checking and credit card account in separate browser tabs so that I don't need to go back and forth to find some information. This is not impractical. You may not remember but I asked the same question few months ago. The example that I mentioned was, you manage Servlet, JSP and HTML forums. You may want to open it in separate tabs and just refresh it whenever necessary to see if there are any new posts posted. Ofcourse, this is about personal preferences.