Navigating directly to '<website>/umbraco' fails to set the ASP.NET session cookie

[simonproctor]

When running the site locally or on Umbraco Cloud, editors will bookmark the back office and go there directly.

If they've not already visited the front end of the site, the ASP.NET session cookie isn't present. This causes the screens, post login, to fail cross site validation checks and 417 error codes are thrown ni the developer console.

This can be immediately remedied by going back to the front end, then returning to the back office and reloading.

The result of this issue is that you see a 'white screen of death' rather than the back office UI.

Note:

• Running from within Visual Studio will automatically load the home page so you'll have the cookie, you need to open it in a new browser (preferably a clean, different one for complete separation).
• On umbraco cloud you can tell if you will receive the issue as the web console (browser) shows only the ARRAffinity cookie. The session cookies are not present.
• You can also recreate this by loading the backend login screen, clearing your cookies and reloading

[nul800sebastiaan]

Hi there @simonproctor - that is a very interesting observation and might actually be closely linked to issue #4138 which we could never reproduce.

I haven't reproduced this one yet but it would be interesting to try. I am not sure why that cookie is not being set but I would imagine the fix would then be easy enough.

I'll keep you posted!

[abjerner]

Hi @simonproctor,

What version of Umbraco are you running? Also, to rule out a few things, could you try in another browser or in incognito mode?

I've tried reproducing your issue - both with a my site running in a full IIS server and also just through Visual Studio 2019 (IIS Express). I've used the following steps:

1. Go to <website>/umbraco
2. Clear all cookies via dev tools in Chrome
3. Try to log in

and also

1. Go to <website>/umbraco
2. Clear all cookies via dev tools in Chrome
3. Reload the page
4. Try to log in

All of my attempts so far has been successful.

[nul800sebastiaan]

I've unfortunately also not been able to reproduce this one. Let us know if you have more info @simonproctor !

For now I'll close this but happy to re-open if we can actually find a good way to reproduce.

[simonproctor]

Hi,

This is in Firefox, Chrome and IE. Its in Umbraco 7 (cloud) with no back office customisations, http modules or redirects. I'm happy to share our account details and/or Github privately.

Without that, I can only think that a step to ensure the session is setup and cookies available is present. I could record our symptoms exactly in a video but as you say, if you can't then its hard to know what to do.

Its worth noting, though, that this happens on UCloud and that's what I'm reporting (as well). I'm not reporting about just running this locally. Your test report appears you have done this locally.

Have you tried this on Umbraco Cloud?

I've re-read my report and noted I forgot to mention this was v7. Sorry for that omission and any time you've spent looking at the wrong version.

[GijsHendrickx]

Hi,

In case people still have this issue and are hosting on Azure:

I had the same issue as presented here, where the "UMB-XSRF-TOKEN" and "UMB-XSRF-V" token were not set after an Umbraco login, causing the backoffice to be a blank page, and getting a 417 code back when calling the Umbraco Backoffice API.

I noticed that these two cookies are session cookies, and seeing that this was only the case on our Azure environment, and not local, led me to think that it had to do with how our Azure environment handled sessions.

I got this issue resolved by completely removing the <sessionState> node in our web.config:

<sessionState mode="InProc" customProvider="DefaultSessionProvider"> <providers> <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" /> </providers> </sessionState>

The problem lies within the "mode=InProc", which makes Azure not handle sessions correctly.
Maybe if you have a custom SessionStateProvider already configured (e.g. mode="Custom", not mode="InProc") it is not a good idea to remove this piece of code.

After updating the web.config and restarting the azure app, everything worked fine.

[Shazwazza]

Thanks @GijsHendrickx , i actually think this configuration element might be super legacy, it's prob been there since 3.x and not sure it's even needed, would have to check. But good find!