I am having a really bad issue where no matter what I try, the user is being logged off after 10 minutes.
I am using ASP.Net 2.0 running on IIS 6.0 on Server 2003 R2 Standard Edition running as a Virtual Server with all applicable updates and .Net 3.5 SP1.
The client is Internet Explorer 7.0
Below are the web.config settings:
<!-- Authentication Mode -->
<authentication mode="Forms">
<forms name=".RecipeViewer" timeout="240" />
</authentication>
Below is the code used to set the authorization cookie:
Private Sub SetCookie(userName)
' Use security system to set the UserID within a client-side Cookie
Dim ticket As New FormsAuthenticationTicket(1,userName, DateTime.Now, DateTime.Now.Add(Me.GetFormsAuthSettings.Forms.Timeout), True, String.Empty, FormsAuthentication.FormsCookiePath)
Dim hash As String = FormsAuthentication.Encrypt(ticket)
Dim cookie As New HttpCookie(FormsAuthentication.FormsCookieName, hash)
cookie.HttpOnly = True
If (ticket.IsPersistent) Then
cookie.Expires = ticket.Expiration
End If
Response.Cookies.Add(cookie)
' Redirect browser back to originating page
Response.Redirect(Request.ApplicationPath)
End Sub
Private Function GetFormsAuthSettings() As System.Web.Configuration.AuthenticationSection
Return DirectCast(System.Configuration.ConfigurationManager.GetSection("system.web/authentication"), System.Web.Configuration.AuthenticationSection)
End Function
I was previously using the FormsAuthentication.SetAuthCookie as well as even trying the FormsAuthentication.RedirectFromLoginPage methods, but these both had the same result, which is why I ended up doing the hard cookie implementation that is done internally (via viewing in Reflector) that the FormsAuthentication class does.
The issue is NOT reproduceable in the Visual Studio 2008 asp.net hosting environment or in IIS 7.0.
EDIT: Cookies are enabled, even the hosted site has been added as a trusted site.
EDIT: Google Chrome and Firefox do not have this issue.
EDIT: Verified Cookie on target machine is set to expire after 4 hours as per the setting (timeout = 240 minutes).
EDIT: As House says, everyone lies. User did not actually test the new code base and was going on a pre-conceived notion that the software was still broken. Thank you to everyone who replied in this topic.
Not closing this for no longer relevant, but keeping it around to help people troubleshoot the issue as there are some really good troubleshooting techniques in this question.
Although your requirement is for IE you can use Firefox with Firebug and FireCookie to monitor your cookies and expirations.
In IE you can download IE Developer Toolbar, in wich you can see your cookies values using the Cache \ View Cookie Information menu.
It's strange if it work properly in Google Chrome, maybe you can capture the request using the Application_BeginRequest event in the global.asax and log the cookies received and it's values.
Change your Session State to store using InProc, you are likely facing an issue similar to mine that when the user hit an error the session was essentially just dying every time when it wasn't being stored using InProc.
Session Types: http://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx
It could also (have been) that the machinekey was not set and thus being randomly generated every time the app was initialized (which would mean that the encrypted authentication ticket would be salted with a new key).
I use a site to generate a new machinekey for my apps and stick it in the web.config:
http://www.orcsweb.com/articles/aspnetmachinekey.aspx
Client did not test production code and was still responding from the previous issue before a patch was applied to their production environment.
If you can't replicate it on the same environment, I would recommend a meeting where you can watch them replicate the issue.
Flagging this as answer after 48 hours.
I vaguely recall something about the IIS session timeout settings being able to override whatever you have set in the web.config. Check that your application properties don't set a timeout of 10 minutes (properties->configuration->options).
I've had a similar problem in the past, but I'm not sure it's what you're talking about. Am I right that your problem doesn't happen on production systems (or any system under frequent load)? If so, the problem may be the worker thread idle timeout. You can try changing it or turning it off under IIS Manager->right click Application Pools, go to Performance tab, it's the checkbox under Idle Timeout. The stuff on the Recycling tab of that dialog may also be of interest to you.