Here's a strange issue: I've a website running on Umbraco 7.2.2 which does not appear to allow the user to refresh (i.e. hit F5) after having logged into the backoffice. Here are a sample steps to reproduce:
Even weirder: I am only experiencing this issue on a specific environment i.e. test; refresh appears to work fine on both dev and UAT. It's running the same code and I've confirmed that database is not an issue. I've been comparing IIS settings but they look similar as well; at this point however, it looks like it could only be IIS that would differ between the environments for this specific issue.
Thanks for that Jeroen, that forum post definitely gives me a couple more ideas to debug this.
So, my findings:
Setting debug=true makes the problem go away. Also, I've just noticed that this issue can only be reproduced using Chrome - it appears to be happy with Internet Explorer
However, I'm not getting the same issue as reported with packages causing issues. When I set debug=false and then turn off CustomErrors and tried to hit the GetCurrentUser api endpoint separately and that returned a 200 with the expected payload. It appears that there's something that's blocking the backoffice from hitting that API endpoint.
Finally, it appears to be an environmental issue - for one thing, it's not reproducible on the UAT environment (where debug=false) - but all other Umbraco 7.2.2 websites we have on that same test environment appears to be exhibiting this behaviour.
Interestingly, we have one website on our test environment that's on U 7.2.4 and it doesn't seem to be exhibiting the same issue. So, there is potentially a fix in there that rectifies an edge case that exists on our test environment.
Update: upgrading the affected website to Umbraco 7.2.4 made the problem go away. However, we have another website which went straight up to U 7.2.5 and it appears that the problem has come back. Anyone else experiencing this?
What is different on your live environment? Are the server types different? Do you have dynamic compression or something running on it (either IIS native or some third party IIS plugin)?
If you google: net::ERRCONNECTIONRESET
Nearly all of the responses say that it's some network issue. Perhaps your live environment is doing something different than UAT, different certificates, proxy servers, etc..?
It's super strange. I have two 7.2.x websites sitting on the same web server - the first one is running 7.2.4 and doesn't have this problem (it previously had this issue before I upgraded from 7.2.2 to 7.2.4). The second one is running 7.2.5 and has this problem - but not for all clients i.e. the issue is only reproducible on some specific machines (which is why I had initially thought it had something to do with CD versioning given that generally speaking, 'new' clients are not able to reproduce the problem). Both are set up in IIS in exactly the same way.
If I go into debug mode, the problem goes away - which again, is why I thought it might be related to CD (although I realise going into debug mode could affect a host of other things).
Can you confirm that this is only ever occuring for Chrome and everytime it occurs you get this error: net::ERRCONNECTIONRESET ?
If so, can you give a full trace of all requests in a session until this issue happens and the full details of that request (i.e. output from Fiddler)
Actually the problem is still rearing its ugly head - just not for me specifically; I've some other colleagues in the office who continue to have this same issue.
We've been able to gather up a couple of other pieces of information which may be useful on this:
It appears to affect only a specific backoffice user (which happens to be the first user in the system i.e. the one that Umbraco creates during an install).
When the error occurs, the CMS seems to be blocking on GetCurrentUser (and the backoffice angular app eventually fails to load). When I attempt to call GetCurrentUser on a separate tab, it succeeds (as mentioned above) but it takes a whole lot longer than expected e.g. a minute rather a 1-2 seconds in the case of a successful load. And so potentially, the problem is that the backoffice angular app is timing out...?
I've raised a separate question around any special properties of the 'first user' and whether that has anything to do with this issue.
Sorry for the late response, I've been working on other projects the past week.
So I had a look again and it turns out that the problem must have been to do with networking infrastructure issue in our office - possibly some old Javascript was being cached for some of our machines. Some issues have been rectified in this area recently and now everything is right as rain i.e. without any code or configuration change.
Not able to refresh page in backoffice
Hello
Here's a strange issue: I've a website running on Umbraco 7.2.2 which does not appear to allow the user to refresh (i.e. hit F5) after having logged into the backoffice. Here are a sample steps to reproduce:
If you look at Chrome dev tools, you would notice that we're waiting on a call to http://www.website.com/umbraco/backoffice/UmbracoApi/Authentication/GetCurrentUser which eventually fails. In the browser console:
Even weirder: I am only experiencing this issue on a specific environment i.e. test; refresh appears to work fine on both dev and UAT. It's running the same code and I've confirmed that database is not an issue. I've been comparing IIS settings but they look similar as well; at this point however, it looks like it could only be IIS that would differ between the environments for this specific issue.
Any ideas, please?
Hello,
Not sure if it's the same error, but I also had a blank screen: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/49453-HTTPS-and-BackOffice-logging-in?p=0#comment214219.
If you read that topic hopefully you find a solution.
Jeroen
Thanks for that Jeroen, that forum post definitely gives me a couple more ideas to debug this.
So, my findings:
Update: upgrading the affected website to Umbraco 7.2.4 made the problem go away. However, we have another website which went straight up to U 7.2.5 and it appears that the problem has come back. Anyone else experiencing this?
What is different on your live environment? Are the server types different? Do you have dynamic compression or something running on it (either IIS native or some third party IIS plugin)?
If you google: net::ERRCONNECTIONRESET
Nearly all of the responses say that it's some network issue. Perhaps your live environment is doing something different than UAT, different certificates, proxy servers, etc..?
It's super strange. I have two 7.2.x websites sitting on the same web server - the first one is running 7.2.4 and doesn't have this problem (it previously had this issue before I upgraded from 7.2.2 to 7.2.4). The second one is running 7.2.5 and has this problem - but not for all clients i.e. the issue is only reproducible on some specific machines (which is why I had initially thought it had something to do with CD versioning given that generally speaking, 'new' clients are not able to reproduce the problem). Both are set up in IIS in exactly the same way.
If I go into debug mode, the problem goes away - which again, is why I thought it might be related to CD (although I realise going into debug mode could affect a host of other things).
This is very odd.
Can you confirm that this is only ever occuring for Chrome and everytime it occurs you get this error: net::ERRCONNECTIONRESET ? If so, can you give a full trace of all requests in a session until this issue happens and the full details of that request (i.e. output from Fiddler)
Actually the problem is still rearing its ugly head - just not for me specifically; I've some other colleagues in the office who continue to have this same issue.
We've been able to gather up a couple of other pieces of information which may be useful on this:
I've raised a separate question around any special properties of the 'first user' and whether that has anything to do with this issue.
Sorry for the late response, I've been working on other projects the past week.
So I had a look again and it turns out that the problem must have been to do with networking infrastructure issue in our office - possibly some old Javascript was being cached for some of our machines. Some issues have been rectified in this area recently and now everything is right as rain i.e. without any code or configuration change.
Thanks for responding!
is working on a reply...