I ran into a problem with an internal, older Web Forms application today. It appears that the recent Windows Update from Tuesday (Feb 11, 2014) for .NET 4.5.1, has changed some default configuration settings that are causing problems with the forms authentication loginUrl.

Specifically here’s what didn’t work for me: I have a forms auth setup that looks like this:

<authentication mode="Forms">
  <forms  name="ttw" defaultUrl="~/default.aspx" loginUrl="~/login.aspx" />
</authentication>

After the Tuesday round of Windows update installs of .NET Framework 4.5.1 updates I started seeing problems on logging in. When accessing unauthorized URLs, instead of going to login.aspx, I’d instead get redirected to:

http://localhost/TimeTrakkerWeb/Account/Login

Yup that’s an MVC style default route to the Account Controller’s Login method. But I’m not using MVC and I’ve explicitly requested that I want to use a loginUrl of my own – namely login.aspx.

My app requires a login to work for anything but the home page and login page, so when I fired up the application it died unceremoniously every time it tried to access an unauthorized page, which in turn tried to redirect me to the login page.

My first thought was of course that I had something wrong with my config file – I didn’t. Or maybe in the root Web site – nothing there for form authentication. I double checked the IIS settings to ensure I’m looking at the right place and I did. Nothing had changed so why did it break all of a sudden?

New Identity and Membership Config Defaults

Turns out that the issue is related to the new Membership and Identity features in ASP.NET and apparently some of the defaults have changed. This is causing problems on older applications that are missing some newer ‘dynamic’  configuration settings specifically dumped into the config file. This will likely affect any WebForms application that has been updated to .NET 4.0 or later (definitely 4.5).

Luckily there’s an easy, albeit very non-obvious solution to this problem.

Add the following into your web.config file :

<configuration>
   <appSettings>
     <add key="enableSimpleMembership" value="false" />
   </appSettings>
</configuration>

The default value apparently here is true which causes the automatic forms auth redirection. Since I don’t use membership in my applications – not at the root site, nor in this internal app that runs in a virtual, the membership providers are not set anywhere so my app here is inheriting the ASP.NET default. Which apparently has changed in this latest update.

This will most certainly affect any Web Forms application since you are going to have an ASPX page as a login target. MVC or other routed applications might be OK if they use the standard ~/Account/Login style for logging in. Even though I don’t use membership/identity in any of my applications, I tend to use the standard URLs so luckily none of my online applications broke.

Not Univeral

So the above is happening on my development machine which is running Windows 8.1 and ASP.NET 4.5.1. I double checked a handful of older WebForms apps and all of them exhibit this funky behavior on this box. I also tried it on another test machine running Windows 7 – also updated to the latest patches and I saw the same behavior there!

However, I double checked my live Windows 2008 original server online and it works just fine with those same updates installed. So this is not a universal problem apparently but somehow selective. A number of people have commented on this post, as well as a few private notes I’ve received via email and Twitter. This would account for the fact there’s not a massive outcry for this failure which would be sure to break a lot of applications.

Not Cool

It’s a simple fix and I’m grateful for that. Thanks to James Crowley from the AspInsiders list who had run into this as well and pointed me at this fix.

I suspect this problem is somewhat selective since I haven’t seen anybody else complain about this yet. It would appear if this problem was universally occurring we’d see a lot more outcry as it would affect and cripple practically any WebForms app that uses Forms Auth. I don’t know – drop a comment if you ran into this.

Microsoft is aware of this issue and they’re taking a look.

But it’s disturbing that something as fundamental as the <form auth> tag can break based on a Windows update, which in theory isn’t supposed to change any features. This is clearly a breaking change, but I suspect this will be a short lived bug that if indeed this is as universal as it appears to be it’ll likely be fixed in the next round of updates.

Hopefully this post will save some of you some time trying to hunt this down in the meantime.