We are getting problem were users being kick out of the form and navigates to Login page even if the session has not timed out yet. very frustrating to the users...
It doesn't happen all the time and not to all users. It looks like the Authentication Ticket is somewhat not valid but intermittently.
Is this a common problem with ASP.net forms Authentication???
Anybody can help resolve this problem.
Actually, the ticket may in fact be expiring. Have you actually tracked one to see if it is being renewed correctly? Here's a link to an example of how to get at the ticket, test for sliding expirations, and renewing it.
you should check the authentication token and session both. if either is not set properly logout.
depending on your settings, your session could be alive lot longer then the authentication ticket or vice versa.
you could consider using sliding expiration for auth tokens along with DB session storage if you wanna give user long period of active time.
What do you mean by authentication token? Some users complained that they are even active for less than 5 mins...
Anyway, here's whats in the web config.
<forms loginUrl="logon.aspx" protection="All" name="authCookie" timeout="60" path="/">
I will try to add slidingExpiration="true" and see if we will still get some complains althought we have implemented keepalive in the basepage.
<iframe id="frmKeepAlive" width="1px" height="1px" frameborder="0" src="//xxxxx.net/xxxxx/keepalive.htm">
where the keepalive.htm reloads every 5 mins. So before even the session expires. Server knows that the user is still active.
I will also change the timeout to 60 and see if this will make any difference.
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
Thank you guys for all your reply...
Check the eventlog to see if your app recycles for some reason. If there's a serious resource leak IIS may recycle the app pool to release memory. IIRC it is by default set to recycle if IIS uses more than 60% of RAM.
Yes, eventlog doesn't show any recycling of IIS. Otherwise all of them will be kicked out. Only some users are experiencing this... and some of them after just logging in.
Is there any known issue of Anti -Virus in the client side corrupting the Auth Ticket???
I am "almost" positive that <authentication><forms timeout="value"> is in seconds, but I could be wrong. I usually use 3600 for one hour.
This makes sense to me... renewing the Authorization Ticket...I will give this a rip!
if (authTicket != null && !authTicket.Expired)
FormsAuthenticationTicket newAuthTicket = authTicket;
newAuthTicket = FormsAuthentication.RenewTicketIfOld(authTicket);
string userData = newAuthTicket.UserData;
string roles = userData.Split(',');
new System.Security.Principal.GenericPrincipal(new FormsIdentity(newAuthTicket), roles);
Yes, you're wrong, it is in Minutes:
FormsAuthenticationConfiguration.Timeout Property (System.Web.Configuration)
Are you sure about that? Because the behavior you're experiencing sounds to me that the application recycles! Do you have a machine key in your web.config? If not, you really should create one:
Online tool to create keys for view state validation and encryption
The machinekey is used to encrypt/decrypt the authentication tickets. When no machinekey is specified, ASP.NET will generate one. But when the application recycles, ASP.NET will generate a new one, resulting in the behavior your telling. Because the existing tickets are encrypted using the previous key, with the new key they cannot be decrypted anymore so ASP.NET will force you to login again. Specifying a machine key will solve this
There are two things you can do in order to resolve this issue. Well only If( you have your form authentication and other properties are set correctly).
- Create a Machine Key in your web.config.
- Change the App Pool Process Idle time to higher limit. By default its 20 minutes.
When the process stays idle for more than 20 minutes, it kills the worker process and as well as regenerate the machine key. While the existing cookie on client machine is encrypted with older machine key. As it wont be decrypt using the new machine, the user will be send to login page to re-enter the credentials and so does to create new persistent cookie.