I want to allow users a longer inactivity timeout setting of over 1 hour. I configured in web.config:
<authentication mode="Forms">
<forms name="MYWEBAPP.ASPXAUTH" loginUrl="~/Welkom.aspx" protection="All"
timeout="181" slidingExpiration="true" path="/"/>
</authentication>
The application pool has the advanced setting:
Idle Time-out (minutes): 181
In the login code I configured the ticket and the cookie:
FormsAuthenticationTicket ticket = new ...
ticket.expiration = DateTime.Now.AddMinutes(180);
...
cookie.Expires = ticket.Expiration.AddMinutes(5);
Response.Cookies.Add(cookie);
The MasterPage prints the ticket.expiration in the footer of each web page, so that I can see what is going on internally.
As is widely known, sliding expiration means that the timeout value is incremented only with a GET request after half of the timeout period has passed. I tested as follows:
At login, I see in the footer an expiration time that is 3 hours ahead.
Every once in a while I do something in the web site, but the expiration time does not change.
If I do something when the expiration is less than 90 minutes ahead, the expiration time is updated to 3 hours from that moment.
However, if I wait longer than 60 minutes, and then do something, while the expiration time is still over an hour ahead, I will get the login page.
Does anybody know how to fix this?
To configure the Session Inactivity Timeout, there are FOUR settings. In my question I mention three settings, and timeout and auto logout in asp.net 2.0 with IIS 7 even after doing all the possible settings mentions the fourth setting: SessionState parameter in Web.config.
Related
I'm using asp .NET MVC app, and I've configured
<system.web><sessionState mode="InProc" timeout="90" /></system.web>
but It looks like session still valid only 20 minutes instead of 90, why?
How can I make this effective instead of the 20 (default I suppose)
I've checked te idle time in the application pool, it was 20, is that the cause of the timout? If yes, how can I override this from config file?
The configuration you are posting seems correct.
Try to check also your IIS configuration. From this TechNet link:
Open IIS Manager and navigate to the level you want to manage.
In Features View, double-click ASP.
On the ASP page, under Services, expand Session Properties.
In the Time-out field, enter a time-out value in the format hh:mm:ss. For example, enter 00:15:00 for 15 minutes.
In the Actions pane, click Apply.
If you are using Form Authentication keep in mind that it uses his own timeout that can be set as follows:
<system.web>
<authentication mode="Forms">
<forms timeout="90"/>
</authentication>
<sessionState mode="InProc" timeout="90" />
</system.web>
Because IIS restart the pool (including sessions) each x minutes with no activity, configured by the idle timeout in the settings of the pool itself, in the case if user set 90 minutes of session in the app, if there is no activity, IIS can restart the pool before this 90 minutes ends. Example:
Session is 60 minutes configures in app.config
after 30 minutes of idle, the pool recycle itself
Only one person use the app
1.00pm: user connects, he navigates during 10 minutes and then do nothing on the page (for instacne fill a very large form without submitting, and without ajax calls. At this point, user has session "open" untill 1.00am + 10 minutes + 60 minutes configured = 2.10 am
At 1.50 am, he tried to press submit button but it doesn't work because the app pool was recycling at 1.40 (1.10 + 30 min of idle) so user lost session.
If this is possible that user is anole on the app, idle time must be the same of greater than session time.
We've got a huge problem.
We're using the Belgian eID (electronic identity card, this is a smart card). The Claim which is returned, is used by our Forms Authentication.
Everything works fine, but after 10 minutes (of activity or inactivity, doesn't matter), it automatically logs out.
Here the code fragment where we create the session:
private void CreateSession(ClaimsPrincipal transformedPrincipal)
{
SessionSecurityToken sessionSecurityToken = new SessionSecurityToken(transformedPrincipal, TimeSpan.FromHours(1));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionSecurityToken);
}
In the Web.config, we set the session timeout:
<sessionState cookieless="false" timeout="60" />
On the IIS server, we set the Application Pool Idle Time-out to 8 hours.
We also set the Regular Time Interval of the recycling to 8 hours.
Quick hack:
Set the session 2 minutes later than the forms timeout. This ensures that the session is not killed on the exact second the authentication dies. But remember, sessions are independent of forms (see this blog) for more details.
<system.web>
<authentication mode="Forms">
<forms timeout="20" loginUrl="-- Login Page here --"/>
</authentication>
<sessionState mode="InProc" timeout="22"/>
</system.web>
Deeper investigation:
I would try and work out which one specifically is timing out. This is a fairly easy test, and will save you quite a lot of time.
So, the sections required are these with a timeout of 1 minute and session of 10000
<system.web>
<authentication mode="Forms">
<forms timeout="1" loginUrl="-- Login Page here --"/>
</authentication>
<sessionState mode="InProc" timeout="10000"/>
</system.web>
So login, browse to a page, wait one minute and refresh the site and you should see the login page.
In your favourite browser, open a developer toolbar and browse the cookies that are stored for this site. There should be 2 cookies:
ASP.NET_SessionId - to track your session
.ASPXAUTH - to track your login (unless your browser has deleted it due to expiration)
You should see that the expiration time for the session (ASP.NET_SessionId) is in the future, but the form (.ASPXAUTH) has expired.
Login again, and your session should be the same as before.
Reverse the settings and you should find the reverse is happening i.e you are logged in a for a long period of time, but it is resetting.
Tracing the session end event
One more you can try is in your global ASAX. Make sure your sessionMode='InProc' in your web.config and add a method:
// Only works with sessionMode='InProc'
protected void Session_End(object sender, EventArgs e)
{
if(Debugger.IsAttached)
Debugger.Break();
}
The breakpoint will hit when the session dies, which you may be able to track back via the call stack to the exact reason why is has expired. This can come about when code calls Session.Abandon() as well.
I believe I have studied all related stackoverflow questions as well as other web resources, but am still having this problem a dozen times or more daily in a 24x7 web app that is used by about 20 users at a time.
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied has expired.
Users are saying that they are getting logged out earlier than the 60 minute timeout. (Some of the forms in the app take a long time to fill out. Users are interviewing people and writing notes, which can take a long time. So it's frustrating if you save the form after 20-30 minutes of slowly entering notes and it logs you out when you submit the form.)
Some details:
This is a single web server running IIS 7.5, not a form (the
database is on another box). All servers are VMs
IIS session state
is set to "In Process", and under cookie settings the timeout is 60
minutes.
The App Pool has idle timeout set to 60 minutes and
recycling interval to 29 hours
I don't see any errors in the event log prior to these "ticket expired" messages that indicate a worker
process failed or the app pool was recycled.
And finally a snippet from the web.config:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" timeout="60" protection="All" slidingExpiration="true" />
</authentication>
Any help to track down these session timeouts would be appreciated.
I have used jquery idle timer to track the user inactivity and display a warning before session times out. Also allow the user to renew the session by making a Ajax call. Just for reference you can refer these links
link 1
link2
My session renews every 20 minutes. I've set timeout to 300 minutes but still it renews probably because Application Pool recycles.
I am storing UserId which is Guid in Session which returns null. Problem is when I use Membership using
Membership.GetUser().ProviderUserKey
it works fine. But obviously it makes a database call. How can I prevent this problem from happening? Why does Membership.GetUser().ProviderUserKey succeeds whereas Session doesn't?
In order to complete Jan's and Neil's answers, you should look at your web.config and set both timeouts (sessionState and authentication)
<sessionState timeout="300"/>
Sessionstate timeout specifies the number of minutes a session can be idle before it is abandoned. The default is 20.
<authentication mode="Forms">
<forms loginUrl="Login.aspx" timeout="300" />
</authentication>
Forms timeout is used to specify a limited lifetime for the forms authentication session. The default value is 30 minutes. If a persistent forms authentication cookie is issued, the timeout attribute is also used to set the lifetime of the persistent cookie.
Your session may still be alive (if you set it to 300 minutes) but the ASP.NET membership could be expiring?
Have you increased the authentication timeout too?
<authentication mode="Forms">
<forms loginUrl="Login/" timeout="180"/>
</authentication>
You are mixing authentication and session. These are two completely different concepts.
GetUser() return the currently authenticated user form your MemberShipProvider.
Session and authentication have different timeouts - so its valid that your session times out but the user is still authenticated.
In an ASP.NET MVC2 app, we have the standard login action...
if (ValidateUser(model.Email, model.Password)
{
FormsAuthentication.SetAuthCookie(model.Email, model.RememberMe);
...
where the second parameter to SetAuthCookie is createPersistentCookie with the following documentation:
createPersistentCookie
Type: System.Boolean
true to create a persistent cookie
(one that is saved across browser sessions); otherwise, false.
We would like to have the persistent cookie expire after 2 weeks (i.e., a user could return to the site within 2 weeks and not be required to re-authenticate. After that time they would be asked to login again).
How do we set the expiration for the persistent cookie?
Can you not do this?
<system.web>
<authentication mode="Forms">
<forms timeout="20160"/>
</authentication>
</system.web>
The timeout is in minutes.
This timeout value is irrespective of whether or not you are creating a persistent cookie. It simply says that if you don't explicitly terminate the cookie (FormsAuthentication.SignOut), it will automatically expire after the given time period.
In other words, if you do:
FormsAuthentication.SetAuthCookie(someMembershipName, false);
Will result in the cookie expiring when:
The user closes the browser, or
The timeout is reached.
As opposed to if you do:
FormsAuthentication.SetAuthCookie(someMembershipName, true);
Will result in the cookie only expiring when the timeout is reached.
HTH
EDIT:
Take from MSDN:
the timeout attribute is described as follows:
Specifies the time, in integer
minutes, after which the cookie
expires. If the SlidingExpiration
attribute is true, the timeout
attribute is a sliding value, expiring
at the specified number of minutes
after the time that the last request
was received. To prevent compromised
performance, and to avoid multiple
browser warnings for users who have
cookie warnings turned on, the cookie
is updated when more than half of the
specified time has elapsed. This might
cause a loss of precision. The default
is "30" (30 minutes).
Note Under ASP.NET V1.1 persistent
cookies do not time out, regardless of
the setting of the timeout attribute.
However, as of ASP.NET V2.0,
persistent cookies do time out
according to the timeout attribute.
In other words, this expiration setting handles the Forms Authentication cookie only.
The Forms Authentication cookie is a client-side cookie, it has nothing to do with other server-side session you may have (ie a Shopping Cart).
That Session is expired with the following setting:
<sessionstate
mode="inproc"
cookieless="false"
timeout="20"