The application sets session.timeout in Application_AcquireRequestState event handler.
Before session expires, there is notification window popping up. It resets session timeout to, say, 3 minutes (normally, it is 30 minutes), through Application_AcquireRequestState.
The notification offers user an option to extend session for another 30 minutes. If user clicks yes, it will reset session timeout for 30 minutes through the previous event handler.
The problem is, though user clicks yes, and session timeout is set correctly, session seems timeout before the set time. This only happens after notification.
The suspicion is when it hits Application_AcquireRequestState, the timeout is already calculated for this request. The new timeout value will be used for next request. So when user clicks yes to extend session, the timeout for current request is not 30 minutes away, it is only 3 minutes away, due to timeout set by the notification window. The yes will only be in effect if user sends another request.
(Notification window has its own timing object)
Can anyone verify this? or point me to a good resource to explain how asp.net manages this?
Thanks!
Session.Timeout is a global setting within the application.
If you're setting the users Timeout to 3 minutes when you pop the window notifying the user that they are about to be logged out, and they don't respond, your Session.Timeout will stay at three minutes until another user resets it - is it possible that this is happening?
Zhaph, the problem is when user clicked "Yes" to extend the session, then walk away.
I think I finally nailed down the problem.
It was as I suspected, but only in "SQLServer" mode. When request comes into Application_AcquireRequestState, the session is already extended (can be verified in ASPState database, ASPStateTempSessions table). If user clicked "Yes", though the new time out value is set, it won't be in effect until next server request. If user walked away without another click, session timed out with the previously set timeout value, which is 3 minutes.
In "InProc" or "StateServer" mode, the session objects are managed by cache, whose expiration can be reset only further in the future but not shrink back to more current time (or it will be ignored).
I use a much simpler mechanism. I don't have the popup extend the session at all. I use a session with a sliding window and when the user clicks the "OK" button in the session expiration notification, it makes an AJAX request back to the server updating the sliding window.
Related
In my asp.net web application when the user logged in i set an isLogged flag in db to true.
I use the Session_End method to set false isLogged flag when the Session expires ( after 120 min).
I test this method in multiple cases:
When user closes the browser without click on logout button, after the timeout time the session_end do his job.
Same thing happens when user lock his device, or his device go in standby.
My problem is that there are some users that "stay logged" if they don't click on logout button.
I'm honest with you, i don't understand why session_end works when client device isn't connected to the website. I thought that the Server did the Session_end job, but if this is true, why for some users didn't work?
The reason could be the browser or the type of device ( mobile or not) ?
If you enabled sliding expiration for the session and the browser makes some permanent AJAX requests, then just leaving a browser window open can keep the session alive forever. As far as how the session end event works:
The Session_OnEnd subroutine is run when the Abandon method has been
called or when the session has expired. A session expires when the
number of minutes specified by the Timeout property passes without a
request being made for the session.
First of all, let me ask this:
Let's say that a web application has its timeout set to 10 minutes. For some reason, the user is idle. If he/she returns and press any key or moves the mouse, it resets the timeout? Or it is based on the last time it went to the server?
And now the second question: is there a way to find the time until the user gets logged off due to innactivity?
From MSDN:
The Timeout property specifies the time-out period assigned to the
Session object for the application, in minutes. If the user does not
refresh or request a page within the time-out period, the session
ends.
So in answer to your question, the timeout is reset if the user sends a request to the server by either navigating to another page or refreshing the current page (or possibly by using some form of AJAX keep-alive method (See this question)).
This article on Code Project provides a pretty good overview of Sessions within ASP.net
For your second question, this gets a little complex as the session timeouts are managed by IIS so your page has no idea how much longer the session will be valid for. I have seen examples where another timer is placed with in the page itself and when this reaches a certain low value the user is warned that their session is about to expire. The page could then refresh (resetting the session timeout value in IIS) and the user wouldn't be logged out / lose their session.
However, this will require the session timeout value that is configured is kept in sync with the value configured in the JavaScript function.
I am putting an "online" counter on a website, and I have run into these two contradicting sources.
This one (I am using this example code):
http://aspdotnetfaq.com/Faq/How-to-show-number-of-online-users-visitors-for-ASP-NET-website.aspx
...says that:
Also when user closes his browser or does not click on any links in
our website, session expires, and our "OnlineUsers" global variable
is decreased.
However, this one:
http://www.velocityreviews.com/forums/t383710-session-end-guarantee.html
...says that:
Closing the browser window, or browsing to another site will NOT cause
Session_End to fire, at least, not straightaway - the server has
absolutely no way of knowing what happens on the client machine until
it gets another HttpRequest from it. In this instance, Session_End
will fire when the session times out naturally.
I have tested and it seems that Session_End DOES NOT fire.
I basically want you guys to confirm or comment on this.
Is it possible to update the online counter on browser-close?
The second is true
Closing the browser window, or browsing to another site will NOT cause
Session_End to fire, at least, not straightaway - the server has
absolutely no way of knowing what happens on the client machine until
it gets another HttpRequest from it. In this instance, Session_End
will fire when the session times out naturally.
Session time out is 20 minutes by default. You can confirm this by not doing any activity on your website for 20 min.
Your two links are not contradictory. The first link is poorly worded, but it basically says what the second link says. It would be easier to understand if it were written like this:
Also when user closes his browser or does not click on any links in our website (after a period of time) the session will expire, and our "OnlineUsers" global variable is decreased.
Also note that Session_End may not always fire, especially if the session is killed or bounced (for example, if you update the web.config, the worker process recycles, or in some cases an uncaught exception occurs).
As is pointed out later in the first link posted the Session_End event fires after the session timeout expires. If the user who is associated with a session sends no requests to the server before the session timeout value expires the session_end event will be fired and the session will be removed from memory.
MSDN for asp.net session state: http://msdn.microsoft.com/en-us/library/ms178581.aspx
I have read that asp.net session variable last by default 20 minutes of inactive browser.
What happens if the user logs out and immediatly logs in? Or closes the browser and restart it? The session state "dies" ?
If not- what is the alternative to make it die on evey log-out or browser closing?
Thanks
Session state relies completely on the presence of a cookie being provided by the browser for each request in the 'session'. When the server takes receipt of the cookie on each request it then checks if the default 20 mins has passed since the last request.
Therefore the answers to your questions:
What happens if the user logs out and
immediatly logs in?
The cookie is marked as invalid by the server on logout and is assigned a brand new one when they log back in
Or closes the browser and restart it?
Provided the session hasn't expired it won't make any difference (as the browser will still send the cookie along with each request)
make it die on evey log-out or browser
closing?
You can't make a cookie 'die' although you can set it's expired date to the past. There is no way you can detect the user closing their browser.
Whether the session remains active relies on two things:
Whether the Session is still alive on the server (your 20 minute timeout, or you programmatically abandoning the session)
Whethet the client (browser) transports the Session cookie to the server, so the session can be identified.
The Session cookies are served as non-persistent cookies, meaning that they should be maintained by the browser for one session (of the browser), so they should not be sent after you close the browser and restart it. But in reality, it is entirely up to the client browser implementation.
The lesson here: Yes, Sessions expire when the average user closes his browser. But you can't and shouldn't rely on it for anything important.
On log out you might have to clear session manually.
New instance of browser should have new session.
Session.Abandon() will flush all your session. Call this when the user logs out. So every time he logout and logs in, new session will be created. Session TimeOut and Closing a browser will automatically result in a new session next time.
A session "dies" after 20 minutes of inactivity (by default), or if it was cleared by the programmer.
To clear a session, you call the Abandon method on it. Do that on logout.
There is no simple way to detect that a browser window has closed (you can use Ajax to poll from the browser, for example), since the web is stateless. However, if this happens (and no other instances of the browser are still open), when the user starts a new instance and accesses your website, he will get a new session (though the existing one will linger on till it times out).
I'm assuming when you want the user to be logged out - you want the Session to be destroyed, not just the Session Key / Value pairs to be removed.
Calling:
Session.Abandon();
Will destroy the Session.
http://msdn.microsoft.com/en-us/library/ms524310(v=vs.90).aspx
Is there a way to do a Session.Abandon() when the user just kills the session by X'ing out with the little red X box in the upper right corner? I am seeing situations where after an "X out", the user comes back in and it seems like session variables are still present? I guess explorer keeps them intact? (I am unsure of this).
You can try doing an AJAX type callback in the OnUnload event - however, as someone else mentioned you'd have to be aware of other tabs being open (not easy), and it still won't guarantee you get that event.
There's a combination of things to do to get a similar type of effect.
Session Cookie should have a null/empty expiry time. This ensures the browser deletes the session from it's end after the browser is closed.
The ASP Session can be set with a short SessionState timeout value. This means if there's no client activity within that period, the Session will expire.
The side effect of this is that if a user is just looking at the site, and not performing activity (regardless of whether the browser is still open) - the session can expire.
This can be worked-around by having a Javascript timer periodically ping back to the server with an AJAX call or similar. The side effect of THIS is that it generates more site traffic.
The server is typically not aware of such events on the client. The only way the server can be notified about anything is if there is a request sent back to it. I guess you could create such a notification in a JavaScript, but then you should also keep in mind that the session in mind that the session is not per-page but (usually) per user, which means that you would need to keep track of how many tabs/windows the user has opened so that you don't kill the session when you should not.
Personally, I usually try to design the web apps so that they live well with the default handling of sessions, either providing a specific "Logout" command that will kill the session, or simply let it hit the timeout and die.