I'm developping with OpenCms. When I log in to the workplace, and then visit a page hosted by the same OpenCms instance, my workplace session is killed, that is, the workplace asks me for my password again. This happens in a matter of seconds, so I'm sure it's not because of session timeout. If I do it in 2 different browsers, it doesn't happen :\
Any clues why this is hapening?
Thanks
Related
Several times per day (though we cannot reproduce it ourselves), we're seeing instances of sessions being dropped.
What I mean is I have logs of the user coming to the site, performing a few requests, and then having each of their next few requests get a different session identifier and thus wiping out everything in their session. Same IP, same browser, and all of this happens in the course of a couple seconds. The session timeout is configured to 20 minutes.
It doesn't appear to be related to a specific browser, as users have claimed coworkers don't experience the issue on the same machine.
What's really bizarre is that for some requests I can clearly see one session ID coming in through CGI.HTTP_COOKIE and another one is assigned during the course of the request (by the time we get an error email, which is caused by their lack of session). WTF?
To my knowledge, nothing in our application code could be causing this. We use session variables of course, but don't wipe or reset the session ID cookies. I was under the impression that's completely handled by the server.
I'm ripping my hair out here. Any ideas on even how to go about debugging this would be appreciated.
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.
I have implemented application in MVC3 with razor, it working absolutely fine in my development server, after deploying it on serve(Use IIS7 with windows2008) if site keeps idle for 10 to 15 minutes, after that clicking on any link it redirect to Home Page.
I have also set Session timeout on server.
please let me know how i can resolve this issue. Is this Session issue?
First, set the machineKey in your web.config -- see http://aspnetresources.com/tools/machineKey for a generator. This may solve your issue straight up.
If this doesn't resolve the issue, the cause could be several things. Your application could be being unloaded by IIS due to inactivity, or recycled due to excessive memory usage. Both these would terminate all sessions. Another possibility is your authenticated session has expired, if you are authorizing users.
This idle period can be extended through IIS, if necessary. In IIS configuration manager, locate the Application Pool your application is in, right click it and choose 'Advanced Settings' then alter 'Idle Time-out (minutes)'. Note that the default is 20 minutes, more than you are experiencing.
Verify it is not recycling due to excessive memory usage by watching the w3p process in Task Manager. If you see your instance growing large, then disappearing, this is likely the cause.
Last possibly is if you are using Forms authentication and the ticket has expired, your web.config file may be directing people to home page.
How does fast user switching affect a windows service? Are the services suspended or do they keep running in the background when a different user logs in?
On Vista, services run in session 0. This session is always running. User sessions are session 1 on up. Even as users connect and disconnect from sessions, log on to new sessions, and so on, the services keep running and session 0 is never torn down. The only effect on services is they (optionally) receive notifications such as session connect, log on, and so on.
On XP, services run in session 0 and so does the initial user who logs on. This session is never torn down, and may or may not have an interactive user connected to it. Besides this, the behavior is the same as Vista.
They keep running; they run as their own users (whatever you set).
Windows services run in the background even if no user is logged in. Switching between users should have no impact on a properly written service.
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.