There's one ASP.NET MVC page that is automatically refreshed every 2 minutes using the meta refresh tag. All other pages in the application does not have this auto refresh. The application uses SQL server sesssion state and timeout is set to 20 minutes. If user is on any page, it times out exactly after 20 minutes but if the user is on that specific page, where the auto refresh is set to every 2 minutes, it does not timeout after 20 minutes. Is there a way to auto refresh the page and also timeout the user after 20 minutes i.e basically being able to differentiate between user-driven action and system driven auto refresh?
No. Session timeouts are sliding. Every request the user makes to the website resets the timeout. There's no way around that.
Related
I have an ASP.NET MVC application. I have the following:
<sessionState timeout="60" />
My question is that if a user goes on a page and takes more than 60 minutes to fill out all the fields on the page, will that constitute a timeout? What constitutes a timeout? Does a user need to go through different pages so timeout will not happen?
Simple answer is - Yes, a person taking more than the timeout (60 minutes in your example) on the same page would cause a timeout.
Session is server side, so if no requests are sent to the server for the timeout period - the session will expire and all the saved session variables will be lost.
To complicate things a little bit, if your page is making AJAX calls to the server - those could keep the session alive without navigating to a different page.
session data is stored for 60 minutes from the last request. So, if you access a page and something is stored as session data for you, it will be automatically removed after 60 minutes unless you have made a new request within this time period.
you shouldn't try to use sessions to store data for long periods of time.
I'm using devise timeout table to expire a session, however the redirect only happens after a page refresh or change. What is a good solution to redirect to sign in once the session expires?
You need to use some client side code to keep track. If the page is static, you can just do it in javascript:
// Redirect 15 minutes after page loads.
setTimeout(function(){ window.location.href="the_new_place"; }, 1000 * 60 * 15);
If your page has some user controls and you want to keep the session alive while user is editing something, check out https://github.com/epigenesys/session-timeout-prompter.
ActionCable is another possibility but that's perhaps a little heavy-handed for this purpose.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/ms178581(v=vs.100).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
A session is considered active as long as requests continue to be made
with the same SessionID value. If the time between requests for a
particular session exceeds the specified time-out value in minutes,
the session is considered expired. Requests made with an expired
SessionID value result in a new session.
I want to make sure I understand that paragraph correctly. From that I read that ASP.NET Sessions work on a Sliding rule, not an absolute rule. That is, a Session will expire 20 minutes after the LAST request to the session (assuming the 20 min default here for argument sake), not absolutely 20 minutes later from the start of the session regardless of request/session activity? I got that right?
Yes you understood it right.
As the docs say each request to the session will reset the 20 min countdown.
My site uses ASP.Net MVC 5.2.2 and ASP.Net Identity 2.1.0. In CookieAuthenticationOptions I set the ExpireTimeSpan to 30 minutes and the security stamp validation interval is set to 2 minutes (so that users will be booted out within two minutes of a call to UserManager.UpdateSecurityStampAsync.
The problem is that if users remain idle for longer than 2 minutes and then click on the Sign Out button, the site fails to log them off. After a bit of sleuthing, I found that in these cases the server returns a new application cookie (the cookie sent to the server was different than the one returned from it). What seems to be happening is that the owin code misses the call to AuthenticationManager.SignOut and goes ahead with the generation of a new application cookie, as it normally would have in cases where the old one is more than two minutes old.
Has anybody else encountered this issue? Any suggestions on how to diagnose and fix?
I am using VS 2013 Update 3, but this issue existed with previous versions of Identity.
UPDATE:
As an experiment, I created a brand new ASP.NET Web Application project with the VS 2013 Update 3 templates and noticed the exact same issue: I logged in and then waited for an amount of time equal to the security stamp validateInterval (by default, 30 minutes). After that I clicked the Log Off link and noticed that, just like in my own project, a) I was not logged out, and b) a new security stamp cookie was issued to me. I had to click the link a second time to be logged out. In fact, I didn't even need to sit idle for 30 minutes: I could keep making requests during that period and the click to the log out button would still fail, as long as it was the first request after the 30-minute interval expired.
This seems to be a bug in the OWIN identity code. Basically, if the first request after the validation interval is a signout request, it fails, because the code that validates and issues a new security stamp does not check if the user has logged out as part of the same request. Log out requests will fail, as long as they are part of a request that would cause the re-issuance of the security stamp -- i.e. the first request that is after validationInterval minutes since issuance of the previous security stamp.
I would appreciate it if somebody could confirm this behavior. You don't have to wait 30 minutes and do not have to create a new project. Just take an existing project that uses Identity, temporarily set the validation interval to something really short (30 seconds or a minute), log in, and ensure that the first request after the interval expires is a click on the Logout button. If this is a bug, you should notice that you are still logged in.
I also experienced the same issue.
I resolved the issue by changing my AuthenticationManager.SignOut to specify an authentication type as follows:
AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie, DefaultAuthenticationTypes.ExternalCookie);
Also, your OWIN components should be on version 3.0.0 (Which should be the case, since you're using Identity 2.1.0)
In magento, the value of the cookie life time we set from the admin control panel , is browser dependent.
I set the cookie life time value for my default store configuration scope as 600 seconds.
I want to know if this value is browser dependent. Suppose I login to my store at 10 20 am in firefox and 10 25 am in internet explorer, by using the same login id. Then what will happen after 600 seconds, to both these browsers.
Sessions are in most cases tied to the useragent (browser), thus logging into the same account from two different browsers/browser sessions will create two different server-side sessions with each one having it's own expiry time. Some systems don't allow multiple sessions to be started for the same account, but in my experience this is not the case with Magento.