I have a PHP application (although I suppose the general concept would be the same with web applications in other languages) that is supposed to destroy the user's current session after 300 seconds of inactivity. But is there a good way to test that this actually works? I started up my application and let it sit idle for 300 seconds, then clicked on a link and got redirected to the login page -- which is what's supposed to happen when the session is destroyed. Then I did the same thing after only 290 seconds and again I got re-directed to the login page. So either my timing was off, or there's a bug in my checking for session timeout, or there's a bug in my setting the length of time before session timeout. How do I figure out which one it is?
Also, is there a way that I can figure this out without having to wait for the application to timeout with each test? Thanks.
How about setting the timeout to something more manageable/testable like 30s?
As well, when you create a session you can log emit when it should expire. Set a stopwatch, and verify.
Related
I have an classic ASP site on IIS(both IIS 6,and 8) and both perform the same. We've had this issue for years on IIS 5,6,7,8 and never could figure it out. I have a time out setting on the IIS application pool settings of 120 minutes. I do not have a session.timeout setting in any of the ASP code itself. I do have a Session.Abandon in the global.asa file, which works well.
Most of the time if a user is idle for > 120 minutes, it gives them a message that their session has timed out, expires the sessions and redirects them back to the login page.. this is how it should work and most of the time is does.
The issue I have is that about 5% of the time, some users seem to be able to keep the session alive beyond the 120 minutes. Some for days.
I'm wondering if anyone has any ideas what could cause this? Some ideas that I think could cause this??
I assume they keep their browsers open for days, but could a user that has a browser window open but sitting idle AND on another TAB of that same browser be active on other websites? Does that activity make the TAB with my application still active/not idle? I've tested this on several environments but not able to replicate.
Some type of software like a URL filter, proxy server or Antivirus could be causing their browser to not be idle?
Of course a user can keep the session idle if they use the app beyond the 2 hours, but it is rather unlikely they do this, especially for days.
Its hard to troubleshoot since the users are all customers. So I have no clue if its a certain browser, browser version, or their network environment.
Any ideas?
have you tried out to set the timeout in the Application_OnStart method in global.asa?
I had a similar problem, but in my case the session ended up before timeout.
After I set up timeout the problem was solved, just including this line:
Session.Timeout=20
Hope it helps.
Im doing session timeout with php. Im calling php
through ajax. After X seconds of inactivity, if a user
sends a request it is redirected to login page as session has already expired.
How do I send a session timeout message back to browser automatically
and not waiting for a request trigger?
Like, I should have a thread running in the background to check the time
always? Do you have ideas guys?
Thanks a lot.
Sending a request from the server to the browser via ajax is known as long polling, or "comet". It is a proven technique, but now without pitfalls.
For one, a connection need be kept open for each user. That's a lot of overhead, so it should be done with something like NodeJS. Even so, the long poll need be reset every 20s or so, which result in fickle code. Newer browsers introduce websockets, which improve things but require a framework with fallback mechanisms. The question is whether it's worth it for your application.
What I would do in your situation is implement the same timeout mechanism in JavaScript. That way, the user gets a nice message when the session times out in JavaScript, and the server enforces the timeout in case the user bypasses the browser for some reason.
It's easy enough to build an Ajax app which checks all responses to make sure they aren't indicative of a session expiry, and if the session has expired automatically log the user out with a friendly "Your session timed out due to inactivity" error message.
But a common occurrence in Ajax applications is that:
User is logged in, happily using app, retrieving data over http with an established http session
User closes laptop
Host times out http session after N minutes
User reopens laptop later on. Ajax app appears alive and well. They click around which is just fine since the app lets them see things they've already loaded.
Then, they click on something that requires data to be loaded, and the data comes back indicating session expiration
The Ajax app kicks them out and says "Your session timed out due to inactivity".
This is really weird to the user because they were not inactive from their point of view.
Now, one possibility is to have Javascript code in the client which uses setTimeout() to periodically (say, every 15 minutes if the session timeout is 30 minutes) trigger a request to the host to ask how much time is left in the session. This periodic check is great because it lets you show them a warning when they are close to timing out, e.g. "You're session will time out in 1 minute unless you do something".
But that doesn't help when the user's machine is suspended. That's because according to all my testing in many different browsers, setTimeout time applies to elapsed running time instead of elapsed real time. That is, if you call setTimeout("alert('hi')",2*60*1000); and then suspend your machine 10 seconds later, wait 5 minutes, and reactivate your machine, you'll have wait 110 more seconds until you get that alert (I have not been able to find definitive documentation of this behavior but it is a demonstrable fact). So that means your period check may not happen for quite after the user's machine resumes.
My solution to this is to, instead of having my periodic check based on on a long setTimeout, instead do a short setTimeout (say, every 5 seconds), and check the elapsed time since the last check using new Date().getTime() to get the actual clock time. This way I am always checking against the real clock, and instead of the client waiting from zero to fifteen minutes before realizing it has timed out after a suspension, at most it will wait about five seconds (plus http response time) to find out.
But I dislike this solution because it relies on a frequent timer based interruption. Is there a smarter way to handle this?
With big sites like facebook, which is rich with interactive updates, you'll find that there is a combination of all sorts different mechanisms. I'd guess that they're doing validation both on API requests and on Push requests (since someone once told me they use push in addition to ajax)
Timeouts: One thing to consider is that if you store session data in a cookie, having that cookie expire is the same as no longer being logged in. Since the cookie is a hashed value of a few things like a user ID, or a timestamp, it is really easy to see that a session is no longer valid on the very first function call to the API.
Long polling: if a site uses long polling in which a connection is opened indefinitely to await a response from the web server, then closing your computer would kill that connection.
However, if they're just doing regular ajax polling with a reoccurring function call via setInterval, then the web server would automatically know whether the user should get data in return based on the timestamp in their hashed cookie, assuming there is one to check. Those are the types of things that get sent in the header.
Some services actually update a database field that stores your timestamp of last activity and then expires if a certain amount of time has elapsed. This is a less efficient way to do it since it keep track of state.
There's really quite a few ways sites do these things.
I am using ASP classic (1.1) with IIS 6.0. Is there any options to set session never expire?
thanks in advance,
George
Session.Timeout=5
Would mean that it times out in 5 minutes. I don't think you can set this to infinity but you can set it to an approximately large number.
You can specify a Session.Timeout value in minutes.
Or have your pages poll the server every n minutes (a javascript function would do that, or you can have a dummy iframe with refresh-content set to call a dummy asp page every n minutes).
This is better (albeit polling can be taxing on your server, don't poll too often) because if you set your session timeout to a very high (or infinite...) value you'll end up with asp crashing with an out of memory error (I guess the application pool will be restarted).
The session is kept alive when the user calls any asp page on your application before the timeout expires. If your user closes its browser, there's no way your app will be notified and asp will have to wait for the timeout to clean the memory. That means that the session will stay in memory for n minutes after the user is gone, n being the timeout.
There's no need to have an infinite session (it can be addressed by polling) and tweaking with the timeout parameter will make your application more fragile.
If you want to store information for a long while (basically, for the whole life of your application) you'd better use the Application object, which is a dictionary just like Session but is a singleton and can be accessed by anyone on the server.
Steps for changing the website/ASP Session Time-out:
Open the IIS Manager from the Control panel.
Select your website
locate "ASP" under the IIS group in the right-side panel and double click for advanced properties.
locate time-out under Session Properties
Set session time-out as you needed.
Select Apply in the Action Pane to save the changes made.
furthermore, refer to the below screenshots
The session timeout in web applications typically denotes the idle time - i.e. the period of time when the user doesn't work with the application.
Now, what if there is an automated script written that posts a request every 5 minutes - wouldn't that user's session go on endlessly? This being the case, won't this approach heavily load the application affecting its performance in the long run?
Running an automated call to the server, say via an AJAX request, will keep the session alive. Typically that's the point though. An interesting side effect of this is that if the request happens predictably and regularly, you can use it as a "ping" to determine if the user's browser is still open. If one or two pings are missed, you can close the session earlier and actually free up resources sooner than if you just let the session time out.
Yes, and Yes.
This is why if you're going to write an application for the web, you really want to find a way to implement it without using server side sessions. Usually, you will be able to find ways to implement the same functionality using cookies -- then the session data is client-side so who cares if they stay active permanently.
I did something similar for an application that relies heavily on session data.
What I did was set the IIS timeout to a relatively low number, say 10 minutes, then have a timed AJAX call that pings a blank page every 5 minutes.
This overhead on this is actually fairly low, as all you are doing is requesting a blank page, and if a person closes their browser, the session ends in 10 minutes.
You want to keep session as small as possible. That said, if everyone starts doing that, of course it will load your application, with(out) session. If you think your users are compelled to do that, consider why, as either your application is missing an important feature or is forcing them into something.
Now, regardless of that, if you are expecting lots of users to be active at the same time, so much than a single server won't do, then you would will end up having the session out of process. If the session is in Sql Server, it is just saved data, so in that case we wouldn't be talking about memory usage.
Well... I guess "It Depends" The first question you should ask yourself is whether you even need session.
If you have an automated process, my guess is that you don't really need to use session.
In that case, either turn it off or don't worry about it.
I guess your session table would be a little bit larger, but on the other hand you won't be tearing down and recreating the session. I don't see how this would "heavily load" the application. I suppose it would depend on the application itself and how much memory is used to maintain session state.
It would allow the use's session to go on endlessly, as long as they have their browser open. If need to keep a session alive for an extended period of time, you could also track the sessions via the DB and not in memory.
Also, if you are worried about the indefinite open session, you could implement a timeout from when the session opened and if there is an extended idle time.