Cookieless browsing broken after update KB4580979

New Contributor

Upon running Windows Update KB4580979, .Net 4.7.2 projects that have the SessionStateSection.Cookiless Property set to AutoDetect no longer functions as expected.
Previously, a browser that blocked cookies would be redirected to the same page with the querystring /default.aspx?AspxAutoDetectCookieSupport=1 and upon the system detecting that cookies were not supported it would redirect again to a cookiless session URL e.g. /(X(1)S(adl04pietheradyfawfaqlym))/default.aspx?AspxAutoDetectCookieSupport=1
Since the update, a browser would continously be redirected to /default.aspx?AspxAutoDetectCookieSupport=1 until the redirects exceeded the maximum redirects.

 

Relevant Web.config section:
<configuration>
<system.web>
<sessionState cookieless="AutoDetect" />
</system.web>
</configuration>

 

Windows Server 2019 DataCenter Version 1809
OS Build 17763.1369

4 Replies

@JadenConnors You aren't alone, its taken me days to figure out why this was happening all of a sudden to our sites using cookieless="AutoDetect", especially as UseUri/UseCookies/UseDeviceProfile all work fine.

 

On our Windows 2012 R2 server update KB4578976/KB4579979 causes this same issue, and on our Windows 2016 server update KB4578969 again is the same.

 

Uninstalling these updates returns the expected functionality and stops the redirection loop.

 

I'm not sure how we go about escalation this to Microsoft.

@dcbas Thanks for adding information to the issue. I have explored the other cookieless settings you mentioned but each of them have a drawback or a rewrite of our site. I'm also not sure how to elevate this up to Microsoft as I'm sure others are having this issue too. 

 

Anyone on here have any suggestions on bumping this up the chain of command?

Hoping someone else has some more info on a workaround besides not updating Windows which is not a permanent solution.

@JadenConnors Adding this appSetting to web.config

 

<add key="aspnet:DisableAppPathModifier" value="false" />

 

resolved the issue for me. For more details, see section "Known issues in this security update" at https://support.microsoft.com/en-us/help/4578976/kb4578976

 

Setting the value to true (as suggested in the kb article) did not work for me. In my case I had to set it to false.

 

Tested on Win 10 Pro Build 19042 and Microsoft Windows Server 2012 R2 Standard build 9600