locked
Timeout problem RRS feed

  • Question

  • User-883621491 posted

    I am starting to have users test my web applications for the first time. I am finding that if they sit on a page for 60 seconds or more, whenever they click a button or do some action that causes the page to be submitted after that time, all of the fields on the page go blank. It basically resets everything back to an "initial" state. If they do something on the page before 60 seconds, it is fine. I cannot seem to find anywhere in IIS or my web.config that mentions 60 seconds. I've done some web searching but am not having much luck. I assume that this may have something to do with viewstate, but not sure. I am wondering what I can do or try to increase this timeout. By the way, when I test the application in Visual Studio, I can sit on the page forever and it does not reset, so I am leaning towards this being an IIS setting, but again that's a guess. Thanks.

    Thursday, October 30, 2014 10:56 AM

Answers

  • User-883621491 posted

    This is solved. It was due to the way I structured my site, and setting Windows Authentication on the base page so users would automatically be presented a menu, and then not using Windows Authentication on subdirectories that stored the child applications. By rearranging the menu application so it was in a subdirectory and not at the base of the tree it has solved the problem. I guess this is a well-known problem with Windows Authentication and site configurations, due to IE trying to optimize pages.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 4, 2014 4:05 PM

All replies

  • User-484054684 posted

    1. I believe, the default session timeout is 20 minutes. However, this is the node in web.config to increase it.

    <sessionState timeout="2880" />

    2. Are you using Forms authentication, if so, it is worth to read this discussion: http://forums.asp.net/t/1973513.aspx?Form+Authentication+automatic+sign+out

    <authentication mode="Forms">
          <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>


    3. Here is where you can find out the idle timeout in IIS from app pool settings: http://technet.microsoft.com/en-us/library/cc771956(v=ws.10).aspx

    4. Viewstate shouldn't impact your issue..

    Regards
    Siva

    Thursday, October 30, 2014 11:20 AM
  • User-40287846 posted

    Hi,

    Install the IE toolbar, if already there then press F12, , then press the Network Tab,and click on start capturing , then refresh your page using Ctrl + F5 ,and find out which handler is taking time ,same thing you can do it chrome also. once you find out please review that and make the necessary changes, 

    because page load is taking much time.

    thanks,

    sen

    Thursday, October 30, 2014 11:26 AM
  • User-883621491 posted

    Thanks for your post. This doesn't have anything to do with page loading. The user is just sitting idle on the page for 60 seconds or more. When they then click a button the page fields are blanked out immediately. If they click a button before the 60 seconds, then everything is fine.

    Thursday, October 30, 2014 11:49 AM
  • User-883621491 posted

    Thanks for your post. I am using forms authentication. The problem is that everything you referenced is in minutes, and the lowest value I see is 20 minutes. I don't know why the fields on the page are clearing out as if being reset or blanked out after just 60 seconds.

    Here is my forms tag in web.config, which from what the discussion says means it expires in 60 minutes:

          <forms loginUrl="login/login.aspx" name="adAuthCookie" timeout="60" path="/"/>
    

    Something else I didn't mention is that these applications are hitting a database. In the application I am troubleshooting, the scenario that is happening is like this:

    • log in
    • do a search to return records to a pageview
    • scroll through the pageview, look at records
    • sit on the page doing nothing and wait at least 60 seconds
    • try to scroll the pageview and all records are now gone and the pageview is empty as if there were no records
    Thursday, October 30, 2014 11:54 AM
  • User-883621491 posted

    .

    Thursday, October 30, 2014 11:55 AM
  • User-484054684 posted

    Probably there is something else causing cookie to expire. I don't see any good reason for this to happen.

    However, you may try using slidingExpiration to true to see if that solves the problem.  <forms .... slidingExpiration="true" />

    http://dotnetoffice.wordpress.com/2012/09/21/preventing-session-timeouts-in-c-asp-net/

    Thursday, October 30, 2014 1:39 PM
  • User-883621491 posted

    Setting slidingExpiration did not help. I set it once, and it appeared to help at first. However, I shut down the browser and went in again, and then it started doing the same thing, showing blank pages after 60 seconds.

    I am including the code I use in my login page that sets the cookie. I am hoping something here might stick out if I am doing it wrong:

                        ProgramRights = GetRights()
                        FullName = adAuth.GetUserInfo("FullName", txtUsername.Text)
    
                        'Create the ticket, and add the groups.
                        Dim isCookiePersistent As Boolean = chkPersist.Checked
    
                        Dim userData As StringBuilder = New StringBuilder()
                        userData.Append(txtUsername.Text.Trim.ToUpper)
                        userData.Append("|")
                        userData.Append(adAuth.GetUserInfo("employeeID", txtUsername.Text))
                        userData.Append("|")
                        userData.Append(ProgramRights)
    
                        Dim authTicket As FormsAuthenticationTicket = New FormsAuthenticationTicket(1, _
                            FullName, DateTime.Now, DateTime.Now.AddMinutes(60), isCookiePersistent, userData.ToString)
    
                        'Encrypt the ticket.
                        Dim encryptedTicket As String = FormsAuthentication.Encrypt(authTicket)
    
                        'Create a cookie, and then add the encrypted ticket to the cookie as data.
                        Dim authCookie As HttpCookie = New HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
    
                        If (isCookiePersistent = True) Then
                            authCookie.Expires = authTicket.Expiration
                        End If
                        'Add the cookie to the outgoing cookies collection.
                        Response.Cookies.Add(authCookie)
    
                        'You can redirect now.
                        Response.Redirect(FormsAuthentication.GetRedirectUrl(txtUsername.Text, False))
    

    Thursday, October 30, 2014 3:50 PM
  • User-883621491 posted

    This may be in IE issue. I just tried FireFox and Chrome, and I can let them sit there for several minutes and they don't do this. I am not sure what it is about IE that would be the culprit. I'm going to do more testing to be sure that this holds up.

    Thursday, October 30, 2014 4:09 PM
  • User-484054684 posted

    Are you getting this issue only for persistent cookie, or even for non-persistent?

    Also it is worth to check what are the values in these two properties:

    ticket.Expiration.ToString();
    ticket.Expired.ToString();
    

    More info: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.expiration(v=vs.110).aspx

    What is the timeout value for forms tag by the way - However this shouldn't affect too but just want to check, because you are creating FormsAuthentication ticket manually.
    A good article on timeouts, in case if these details give any clue: http://support.microsoft.com/kb/910443

    Regards
    Siva

    Friday, October 31, 2014 8:22 AM
  • User-883621491 posted

    I have been trying to troubleshoot this through Fiddler. Here is a sample header from the application:

    POST http://test.server.com/testapp/ HTTP/1.1
    Accept: text/html, application/xhtml+xml, */*
    Referer: http://test.server.com/testapp/
    Accept-Language: en-US
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
    Content-Type: application/x-www-form-urlencoded
    Accept-Encoding: gzip, deflate
    Host: test.server.com
    Content-Length: 16498
    Connection: Keep-Alive
    Pragma: no-cache
    Cookie: __utma=41117988.540028367.1415030686.1415030686.1415030686.1; __utmz=41117988.1415030686.1.1.utmcsr=test.com|utmccn=(referral)|utmcmd=referral|utmcct=/testapps/testapp/login/login.aspx; ASP.NET_SessionId=0g0fwulvgth3sua0pi3tabgd; adAuthCookie=0D04C28C862E29E920409
    

    After I sit on the page for over a minute, the header changes to this:

    POST http://test.server.com/testapp/ HTTP/1.1
    Accept: text/html, application/xhtml+xml, */*
    Referer: http://test.server.com/testapp/
    Accept-Language: en-US
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
    Content-Type: application/x-www-form-urlencoded
    Accept-Encoding: gzip, deflate
    Host: test.server.com
    Content-Length: 0
    Connection: Keep-Alive
    Pragma: no-cache
    Cookie: __utma=41117988.540028367.1415030686.1415030686.1415030686.1; __utmz=41117988.1415030686.1.1.utmcsr=test.com|utmccn=(referral)|utmcmd=referral|utmcct=/testapps/testapp/login/login.aspx; ASP.NET_SessionId=0g0fwulvgth3sua0pi3tabgd; adAuthCookie=0D04C28C862E29E920409
    Authorization: Negotiate TlPEKDLEIWPKLVADl4II4gUUUUUUUUUUUUUUUUUUUUAGWKDlSSSSDw==
    

    And the page fields go blank. After I do another function on the page, it goes back to like the first header. So it looks like some sort of authentication negotiation is going on after 1 minute that blanks out the fields. I am not sure if that is really the case as this is all new to me, but every time I've tested this the same thing happens - the headers look like the first one, sit for at least 1 minute, the header with "Authorization: Negotiate" comes up and the fields go blank.

    Monday, November 3, 2014 12:13 PM
  • User-883621491 posted

    This is solved. It was due to the way I structured my site, and setting Windows Authentication on the base page so users would automatically be presented a menu, and then not using Windows Authentication on subdirectories that stored the child applications. By rearranging the menu application so it was in a subdirectory and not at the base of the tree it has solved the problem. I guess this is a well-known problem with Windows Authentication and site configurations, due to IE trying to optimize pages.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 4, 2014 4:05 PM