Let me preface this with saying PEBKAC. I was the problem not ASP.NET. In fact, ASP.NET did exactly what it was suppose to do. So with that, here is my story…
I have spent the entire day trying to figure out why I’m no longer able to login to my website that I’m currently developing. I was able to login before (last week), what has changed. Time to follow the white rabbit down the rabbit hole.
My web application uses a common login site to authenticate me. In this case, I was using lets say login.mydomain.com. login.mywebsite.com is setup with a specified machine key. That way, I can login there and get a session cookie that can be consumed by thecoolapp.mydomain.com. This affectively provides me with a Single
Sign On Service (SSO).
I spent all morning trying to figure out why my version of ‘thecoolapp’ was unable to accept the cookie from login.mydomain.com. I re-cloned my code down to a temp folder and updated IIS to point to the new test site so see if there was an issue with the web application or possibly the application pool. No go. A team member did the exact same thing and his worked fine. At that point (and since we are using Git for our source control – hashed commits), I knew that it couldn’t be the source code since we were running the exact same code.
This can only mean one thing… its my machine. What the heck have I done (installed, setting change, etc.) since last week that may have caused this problem.
So, I uninstalled IIS and reinstalled thinking it would reset something. It didn’t. When that didn’t work I decided to take IIS out of the picture and try to run it using Cassini (Visual Studio Web Development Server). Oh wait, that can’t work because of my fancy login cookie stuff. See, login.mydomain.com sets a wildcard domain wide cookie and Cassini will only work with localhost. However, I added localhost.mydomain.com to my hosts file to point to 127.0.0.1. Let’s try this. Crap, it behaves just like IIS and DOESN’T WORK!
This led me to one conclusion. Windows Updates. I knew about the ASP.NET security update that Scott Guthrie mentioned here, here, and here. Maybe one more time would have done the trick ;).
Looking at the history, Friday evening, I applied KB2416471 and KB2416472. And then it hit me! Duh! What an ID10T! Of course it won’t work. login.mydomain.com doesn’t have the patch! (don’t worry, this isn’t a production URL and is currently in an intranet zone).
So, uninstall the patches, reboot and violas, I can login again. So, if you’re reading this, I hope you didn’t make the same mistakes that I did and remember what you installed on a Friday night.