Users are forced to re-register randomly before reaching session timeout and authorization values.

Question

I have reports and complaints from my user that they will use the screen and immediately return to the login screen at the following request. This does not always happen, but by accident. After viewing the web server, the error detected in the application event log is as follows:

Event ID: 4005 Event Message: Form authentication failed for request. Reason: The attached ticket has expired.

Everything that I read begins with what people ask about web gardens or load balancing. We do not use any of them. We are a single Windows 2003 (32-bit OS, 64-bit) Server with IIS6. This is the only site on this server.

This behavior does not generate any application exceptions or apparent problems for the user. They simply load back to the login screen and are forced to log in. As you can imagine, this is extremely annoying and counterproductive for our users.

Here is what I installed in my web.config for the application in the root:

<authentication mode="Forms"> <forms name=".TcaNet" protection="All" timeout="40" loginUrl="~/Login.aspx" defaultUrl="~/MyHome.aspx" path="/" slidingExpiration="true" requireSSL="false" /> </authentication> 

I also read that if you have any location settings that no longer exist or are dummy, you may have problems. My path attributes are all valid directories, so this should not be a problem:

 <location path="js"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> <location path="images"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> <location path="anon"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> <location path="App_Themes"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> <location path="NonSSL"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> 

The only thing I don’t understand is that my timeout value in the forms property for the auth ticket should match my session timeout value (defined in the application configuration in IIS). I read some things that say that the authentication timeout should be shorter (40) than the session timeout (45) in order to avoid possible complications. In any case, we have users who go to the login screen a minute or two after their last action. Thus, the session should definitely not expire.

Update 2/23/09: I have since set the session timeout and authentication timeout values ​​for both values ​​to 45, and the problem still seems to be happening.

The only other web.config file in the application is located in 1 virtual directory on which the community server is located. The web.config authentication options are as follows:

 <authentication mode="Forms"> <forms name=".TcaNet" protection="All" timeout="40" loginUrl="~/Login.aspx" defaultUrl="~/MyHome.aspx" path="/" slidingExpiration="true" requireSSL="true" /> </authentication> 

And although I do not believe that this applies if you are not in the web garden, I have both the machine key values ​​set in both web.config files the same (removed for convenience):

 <machineKey validationKey="<MYVALIDATIONKEYHERE>" decryptionKey="<MYDECRYPTIONKEYHERE>" validation="SHA1" /> <machineKey validationKey="<MYVALIDATIONKEYHERE>" decryptionKey="<MYDECRYPTIONKEYHERE>" validation="SHA1"/> 

Any help with this would be greatly appreciated. This is apparently one of those issues that gives a ton of Google results, none of which seem to be relevant to my situation so far.

Answer 1

It is also possible to check the Maximum Worker Processes property for the application pool. If you use a memory session and have more than one workflow maximum, you may find session problems because the user request is being processed by another thread that does not know about its session.

Answer 2

Since you noted that you use a very specific FQDN for your site, do you have any other .Net applications running under the same fully qualified domain name, only different virtual paths? The auth cookie name may be the same for both applications, but the token will be different. Therefore, if I sign up for www.domain.com and then for www.domain.com/app2, I will no longer have the correct authentication for the application.

Answer 3

1.) Check how often your iis process is being processed. (Turn on logging and check your settings ). After reuse, using the default session store, the session is lost.

2.) Does your application create Threads that may throw an exception (which are not displayed to the user)? Because if such a situation exists, iis processes processes much more often.

Answer 4

I just finished working with this exact problem, exactly the same as described in the question, and the problem was that there was no configuration in web.config.

When using formsAuthentication, you need to stop authenticating the session descriptor since the cookie is now responsible for it.

This line should be added (or updated) to your web configuration in the "system.web" element

 <sessionState mode="Off"> 

sessionState and formsAuthentication should not be active. I do not understand the subtle details of how they interfere with each other, but in this case he randomly left random users at arbitrary points in time.

Answer 5

Our site has been facing the same problem for many years, but yesterday we found a fix, see my question . As the commentator said, I tried adding this to web.config:

 <sessionState mode="InProc" timeout="60" /> 

Apparently, the timeout should be set in both sessionState and ticket. See Also ms document at https://msdn.microsoft.com/en-us/library/ms178586.aspx

To more accurately measure the actual timeout in debug mode, it was convenient for me to add Debug.WriteLine calls to the Global.asax.cs file in the Session_Start() and Session_End() methods, with the addition of millisecond time using

 string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage); 

so that you can log in, go to lunch, allow a timeout session, and read the timestamps at some convenient point in the VisualStudio output window.