U4-7464 - 7.3.2 - Near Constant Backoffice Timeouts

Created by Brian Powell 26 Nov 2015, 21:03:58 Updated by Paul Wright 02 Oct 2017, 12:59:36

Relates to: U4-7469

Relates to: U4-7380

In v7.3.2, I'm encountering nearly continual session timeouts in the Umbraco backend. I can login, immediately go to make a change, then immediately go to save the change, and my session has timed out already.

Site is an upgrade. I see this issue in Chrome and Firefox (did not test other browsers). I manually cleared cookies and emptied my cache but it didn't make a difference.

The only thing I see in the Umbraco trace log is a note that one of my macro threads is being aborted on the public website, but I'm not sure if it is connect to anything. I don't see anything in the logs about the config changing.

I'm not sure if this is related to U4-7380.

5 Attachments


Brian Powell 26 Nov 2015, 21:04:54

Maybe issue wasn't fixed? I'm seeing this problem in 7.3.2 but didn't notice it in 7.3.1.

Nicholas Westby 27 Nov 2015, 09:10:11

@bitmapped I am having the same experience as you (didn't see it in 7.3.1, but am seeing it in 7.3.2). There is some good discussion around this happening in the comments on the issue for 7.3.1: http://issues.umbraco.org/issue/U4-7380

Shannon Deminick 27 Nov 2015, 09:33:32

Do you have custom anything assigned? I.e. custom authCookieDomain, etc... assigned in umbraco configs?

Shannon Deminick 27 Nov 2015, 10:03:56

Hi all, I've kept the discussion going here http://issues.umbraco.org/issue/U4-7380#comment=67-24458

If you have exact steps to replicate, please tell me how because as it stands now, i cannot replicate this issue.

Brian Powell 27 Nov 2015, 11:44:21

I've posted with U4-7380 too, but in case anyone is looking here, it seems in my case that the problem only exists when keepUserLoggedIn is set to true. The timeouts go away when I set it back to its default value of false.

Shannon Deminick 27 Nov 2015, 15:56:38

Hi all,

I've made some changes today. I have streamlined more of the cookie handling to make sure that cookies are always written consistently. I've identified possible issues that are now fixed... though I couldn't actually replicate the issue on my machine:

  • The GetUserSecondsMiddleWare was renewing the ticket and the cookie each time it was accessed if keepUserLoggedIn == true. This isn't necessarily a bad thing and I don't think it causes any issues but it shouldn't do that on each request. It should have been checking if the ticket requires renewing based on it's remaining time. So now that is fixed and inline with how OWIN normally renews tickets. So the cookie will be set when it's required for this request.
  • The ForceRenewalCookieAuthenticationMiddleware could have been the issue when working with Webforms editors (i.e. the current content type editor). This was actually writing 2x auth cookies in the response which may have been causing some odd behaviors, perhaps just with certain browsers (I'm not sure). This has been fixed though and in fact this middleware is only required for legacy webforms editors that don't exist under the /umbraco path. Webforms editors that do exist in that path will have their tickets auto-renewed normally by the normal OWIN cookie auth process.
  • The cookie writing between these two middleware's wasn't perfectly consistent which might have been part of the issue especially when working on SSL
  • The GetUserSecondsMiddleWare wasn't using the CookieOptions.SystemClock.UtcNow and instead using DateTime.Now.ToUniversalTime() ... though i don't think this caused any issues, I've updated it to use the system clock which all OWIN operations normally use.

I have tested this now with:

  • Normal back office operations and have ensured the cookies are written correctly and only when required
  • Webforms editors like the content type editor
  • custom (legacy) webforms editors that inherit from UmbracoEnsuredPage that don't exist under the umbraco path

These tests have all been done:

  • With/without SSL
  • With/without keepUserLoggedIn

These fixes are in revs: 8e6bbc3df9db5f52d264c1b64b2dc8c029dd6286, c4860a490fe9389dad81875c99aac874bcccbcbe

I'm building a nightly 7.3.3 for you to test, i'll post the link shortly.

Nicholas Westby 27 Nov 2015, 16:56:21

@Shandem I created a tag in my repo. Simply clone the repo, switch to the tag, then debug in Visual Studio 2013 to test: https://github.com/rhythmagency/formulate/tree/logout-issue

I'll give the nightly a try once you post the link.

By the way, I wonder if the issue could be that you are setting the domain to null rather than not setting the domain at all. Perhaps ASP.NET interprets the two differently (e.g., maybe it defaults cookie domains based on the request whereas setting it to null explicitly wipes out the domain).

Nicholas Westby 27 Nov 2015, 18:02:28

@Shandem Is the expiration on cookies in UTC? If so, the problem could be that the cookie is set in the past. Here is the expiration time set on the cookie I just got (10:27AM):


And here's the current time in UTC (5:58PM):


Since that time is in the past, that explains why the cookie would get deleted.

And since you are on a different timezone (I'm in California in the US), that may explain why you can't reproduce the issue (i.e., because the cookie time is set based on your current timezone, though the browser may interpret it as UTC).

Shannon Deminick 27 Nov 2015, 20:39:22

Yeah it's something i was thinking about as well, the new code uses the same Utc date/time format as the default OWIN cookie management (CookieOptions.SystemClock.UtcNow)

Our normal build server is acting up but you can get the nightly with all 7.3.3 fixes here: https://ci.appveyor.com/project/SebastiaanJanssen/umbraco-cms-hs8dx/build/1881/artifacts

before we release this we need you guys to test this timeout issue.

Tom Fulton 27 Nov 2015, 21:00:03

@Shandem I tried the nightly and can confirm it looks good now! I've been logged in for the past 10 minutes with no issues. Thanks! #h5yr

Nicholas Westby 27 Nov 2015, 22:31:33

@Shandem It seems to be working for the most part (i.e., I'm not being logged out). Curiously, I noticed it appears to now be a session cookie (which would expire as soon as I close my browser window):


Not sure what the point of setting umbracoTimeOutInMinutes in the web.config is if a session cookie is being used. Also, I noticed GetRemainingTimeoutSeconds is no longer sending a response cookie:


That's strange, as I have keepUserLoggedIn set to true in my umbracoSettings.config. I would expect that call to GetRemainingTimeoutSeconds to continuously respond with a cookie that has incremented the expiration date.

Nicholas Westby 27 Nov 2015, 23:03:35

Did another test. If I log out and back in, it is no longer a session cookie and the cookie seems to respect the value I set in the web.config for GetRemainingTimeoutSeconds. However, it is still the case that the calls to GetRemainingTimeoutSeconds are not sending any response cookies (and so, are no keeping the cookie updated according to the value I set for keepUserLoggedIn in the umbracoSettings.config).

Shannon Deminick 28 Nov 2015, 02:34:59

@Knickerbocker please re-read my detailed response which includes information about this specifically: http://issues.umbraco.org/issue/U4-7464#comment=67-24466

Nicholas Westby 28 Nov 2015, 07:15:18

@Shandem Gotcha. Looks like you're all set. The session cookie is still a little weird, but the fact that it only seems to happen with the auto-login after install is not a big deal.

Shannon Deminick 28 Nov 2015, 09:34:58

You get a session cookie after install because we don't want to create a persisted cookie for that user creation and auto login scenario, it's expected behavior. So yes, after you install and then close your browser you'll need to login again.

Sebastiaan Janssen 28 Nov 2015, 11:18:37

Our Teamcity server is currently acting up, but a nightly build is available from AppVeyor:


If you could please try again with this version to confirm that the issue is now fixed, that would be great, thanks!

Brian Powell 28 Nov 2015, 14:57:20

I'm traveling today. I will check when I get home this evening.

Brian Powell 30 Nov 2015, 01:49:45

I upgraded my testing install with the new 7.3.3 code. It seems to be working OK.

Sebastiaan Janssen 30 Nov 2015, 17:29:40

Thanks @bitmapped !

@Knickerbocker If you have 5-10 minutes to test the above build too that would be very helpful! https://ci.appveyor.com/project/SebastiaanJanssen/umbraco-cms-hs8dx/build/1881/artifacts

Nicholas Westby 30 Nov 2015, 17:56:05

@sebastiaan I had already tested it the first time you posted the link (I was unsure why @Shandem posted the same link a second time asking for people to test again).


Nicholas Westby 30 Nov 2015, 17:57:35

@sebastiaan Actually, it looks like @Shandem was the first to post the link, so I'm not sure why you posted the same link a second time.

Sebastiaan Janssen 30 Nov 2015, 18:08:25

Duh.. looks like I missed that :-) All good then, thanks again!

Sebastiaan Janssen 01 Dec 2015, 10:35:39

Thanks again for your testing people, 7.3.3 is out now!

Nicholas Westby 03 Dec 2015, 18:52:30

@sebastiaan FYI, it appears that this was not fully fixed: http://issues.umbraco.org/issue/U4-7495

Paul Wright 02 Oct 2017, 12:59:36

Im not techy person - But could the hour invoked by "BST", be the cause of this. I notice if I change the umbracoTimeOutInMinutes to 80, that seems to set the cookie expiration to +20 mins of the current time.

Priority: Critical

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.3.2

Due in version: 7.3.3


Story Points: