I have a session variable and it is set default time of 20 minutes... Is it possible to see the running time of that session variable (ie) say 14 min 35 sec..
If you are already in the codebehind, your session will always be renewed to the specified timeout as the request has already been processed. The same goes for FormsAuthentication ticket, to some degree, depending on the sliding expiration settings.
The only valid use case for auditing session/ticket timeout is in an AJAX scenario.
Auditing session and/or forms ticket lifetime is a tricky proposition because you have to go to the server to access the httpOnly cookie in order to determine the timeout which, in most any scenario, results in refreshing the cookie/ticket leaving you with a catch 22 which results in a never ending session.
I have developed a solution to this problem using a custom HttpModule that exposes 2 virtual endpoints that returns a value representing the remaining life of the session/ticket. You can access these endpoints from javascript or managed code.
Find the implementation and example solution here: AsynchronousSessionAuditor
Related
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've an ASP.NET web site that uses FormsAuthentication and a standard Session mechanism. In one of it's webpage the processing(on click of refresh button grid rebinds) is base on session value.If i leaves the screen open for a 'long time' and then tries the refresh. Nothing refreshes.It because session value expires.
So is there any way, i can set configure setting in web.config and synchronize both authentication cookie timeout and session timeout ?
In web.config, set the timeout value of the sessionState element, and the same value in the authentication element.
First, see this SO thread for your answer.
You can attempt to "synch" - perhaps by logging in and setting session vars in the same method, but that's not really a "setting"....
What follows is just my take/opinion that expands on that answer.
IMHO, I think you need to rethink what each type of "storage" is for. Forms Authentication is exactly for that purpose - authentication to some "content" or "resource" that you deem needs to be protected.
Session is more for exactly that - e.g. because some data/resource is "volatile" (changes within x time) - the usual example for this is if you have an ecommerce site, you have to track inventory changes for availability of a product (inventory changes because of purchases/returns made by users, while other users are browsing/shopping). That or the simpler process of users adding items to a cart (sessions and/or cookies, aka "persistence").
Its important to know that on the client (browser), cookies are the primary mechanism for sessions (or url for cookie-less sessions).
So depending on what content/resource it is you are referring to, change the process depending on which of the 2 types they fall under.
if it's a protected resource then display/access should be controlled by your auth scheme
if it's volatile/changing content/persistence needs, then sessions or just cookies might fit the bill (or newer client side storage)
if it's both (protected and volatile) then, auth first and then whatever mechanism fits the bill for volatile/persisted content.
Hth....
I have a problem of the session not expiring. Here is my case
I have a application in asp.net1.1. i am able to handle session when user click logout button. Session is active for 35 minutes. the application is also check if same user is trying to login using multiple machine and blocks it.
Now this application is deployed in city where there is power outage. When user is loggd in and light goes off, the session remain open. Due to this, the user is not able to log in again for next 35 minutes from alternate machine.
Can you tell solution of how to handle issue of session remained open the right way?
Did you write the code that if a session already exists, refuse another login? If so, you will probably have to change it. It is more common to kill the old session and start a new one if necessary. I prefer to allow multiple sessions for a single user unless there is some specific security requirement not too.
Lookup the SessionState timeout field in Web.config.
Best solution is to add UPS to the client workstations so they don't lose the connection if the power goes out. The only other option I can think of in this situation is to add something to the login code which, instead of blocking an alternate location login, instead forces the other session to be expired on a successful login.
We solved some similar issue this way:
in the body of the asp.net page, we attach on the onload event an ajax call. In this ajax call, the session timeout is set to 35 mins.
Also an ajax call is attached to the onunload, where we set the session timeout to 1 min.
This way the user has 35 min timeout when using the application, yet has 1 minute timeout when closing the application.
I am trying to use Channel Factory and caching it in my asp.net mvc.
I am using PerSession Instance mode as I need to know the state.
Because of this I cannot close the proxy immediately. And I dont want
to reopen ,close proxy everytime.
If I leave the proxy open it is timing out at the 12th time. I can
increase the concurrent session timeout but I want to know if it is
the right approach to go.
I am new to WCF so pardon If my question is stupid.
-Thanks in advance
Pratt
The answer maybe activating the slidingExpiration property in the forms authentication element, although by default this is turned on. With this, after each call the timer is reset to the timeout value so the session stays active whilst it's in use.
See this MSDN Link: Forms Authentication & slidingExpiration property
EDIT - response to comment:
Yes, when the session timeout is reached you will need to reauthenticate before being able to accesss the services again. You should set the timeout value to the length of inactivity (in minutes) that you would consider the user is no longer active (default 30 mins), then the sliding expiration will reset this value if the user keeps calling. I'd try doing some simple tests with the timeout set to 1 minute with different scenarios to prove it to yourself.
By default the session expiry seems to be 20 minutes.
Update: I do not want the session to expire until the browser is closed.
Update2: This is my scenario. User logs into site. Plays around the site. Leaves computer to go for a shower (>20 mins ;)). Comes back to computer and should be able to play around. He closes browser, which deletes session cookie. The next time he comes to the site from a new browser instance, he would need to login again.
In PHP I can set session.cookie_lifetime in php.ini to zero to achieve this.
If you want to extend the session beyond 20 minutes, you change the default using the IIS admin or you can set it in the web.config file. For example, to set the timeout to 60 minutes in web.config:
<configuration>
<system.web>
<sessionState timeout="60" />
... other elements omitted ...
</system.web>
... other elements omitted ....
</configuration>
You can do the same for a particular user in code with:
Session.Timeout = 60
Whichever method you choose, you can change the timeout to whatever value you think is reasonable to allow your users to do other things and still maintain their session.
There are downsides of course: for the user, there is the possible security issue of leaving their browser unattended and having it still logged in when someone else starts to use it. For you there is the issue of memory usage on the server - the longer sessions last, the more memory you'll be using at any one time. Whether or not that matters depends on the load on your server.
If you don't want to guesstimate a reasonable extended timeout, you'll need to use one of the other techniques already suggested, requiring some JavaScript running in the browser to ping the server periodically and/or abandon the session when a page is unloaded (provided the user isn't going to another page on your site, of course).
You could set a short session timeout (eg 5 mins) and then get the page to poll the server periodically, either by using Javascript to fire an XmlHttpRequest every 2 minutes, or by having a hidden iframe which points to a page which refreshes itself every 2 minutes.
Once the browser closes, the session would timeout pretty quickly afterwards as there would be nothing to keep it alive.
This is not a new problem, there are several scenarios that must be handled if you want to catch all the ways a session can end, here are general examples of some of them:
The browser instance or tab is closed.
User navigates away from your website using the same browser instance or tab.
The users loses their connection to the internet (this could include power loss to user's computer or any other means).
User walks away from the computer (or in some other way stops interacting with your site).
The server loses power/reboots.
The first two items must be handled by the client sending information to the server, generally you would use javascript to navigate to a logout page that quickly expires the session.
The third and fourth items are normally handled by setting the session state timeout (it can be any amount of time). The amount of time you use is based on finding a value that allows the users to use your site without overwhelming the server. A very rough rule of thumb could be 30 minutes plus or minus 10 minutes. However the appropriate value would probably have to be the subject of another post.
The fifth item is handled based on how you are storing your sessions. Sessions stored in-state will not survive a reboot since they are in the computer's ram. Sessions stored in a db or cookie would survive the reboot. You could handle this as you see fit.
In my limited experience when this issue has come up before, it's been determined that just setting the session timeout to an acceptable value is all that's needed. However it can be done.
This is default. When you have a session, it stores the session in a "Session Cookie", which is automatically deleted when the browser is closed.
If you want to have the session between 2 browser session, you have to set the Cookie.Expired to a date in the feature.
Because the session you talk about is stored by the server, and not the client you can't do what you want.
But consider not using ASP.NET server side session, and instead only rely on cookies.
Unfortunately due to the explicit nature of the web and the fact there is no permanent link between a website server and a users browser it is impossible to tell when a user has closed their browser. There are events and JavaScript which you can implement (e.g. onunload) which you can use to place calls back to the server which in turn could 'kill' a session - Session.Abandon();
You can set the timeout length of a session within the web.config, remember this timeout is based on the time since the last call to the server was placed by the users browser.
Browser timedout did not added.
There's no way to explicitly clear the session if you don't communicate in some way between the client and the server at the point of window closing, so I would expect sending a special URI request to clear the session at the point of receiving a window close message.
My Javascript is not good enough to give you the actual instructions to do that; sorry :(
You cant, as you can't control how the html client response.
Actually why you need to do so? As long as no one can pick up the session to use again, it would expire after that 20 minutes. If resources does matter, set a more aggressive session expiry (most hosting companies did that, which is horribly annoying) or use less objects in session. Try to avoid any kind of object, instead just store the keys for retrieving them, that is a very important design as it helps you to scale your session to a state server when you get big.
Correct me if I am misreading the intent of your question, but the underlying question seems to be less about how to force the session to end when a user closes the browser and more about how to prevent a session from ending until the browser is closed.
I think the real answer to this is to re-evaluate what you are using sessions to do. If you are using them to maintain state, I agree with the other responses that you may be out of luck.
However, a preferred approach is to use a persistent state mechanism with the same scope as the browser session such as a cookie that expires when the browser is closed. That cookie could contain just enough information to re-initiate the session on the server if it has expired since the last request. Combined with a relatively short (5-10 min) session timeout, I think this gives you the best balance between server resource usage and not making the user continually "re-boot" the site.
Oh you have rewritten the question.
That one is absolutely feasible, as long as javascript is alive. Use any timed ajax will do. Check with prototype library http://www.prototypejs.org PeriodicalExecutor or jQuery with the ajax + timer plugin. Setup a dummy page which your executor will call from time to time, so your session is always alive unless if he logouts (kill the ajax timer in the same time) or close browser (which means the executor is killed anyway)