SessionAuthenticationModule Causes Strange Redirect Behavior

I was working on a web project using ASP.NET MVC 4 when I started seeing some strange behavior. Some of my AJAX calls to ASP.NET Web API services were getting redirected back to the same URL. The only difference between the original URL used to make the call and the redirected URL was changes in case sensitivity. While this could just be annoying and cause some performance issues this was causing my application real issues because the redirected web request was missing some header information.  Specifically I was using basic authentication on the calls to the Web API's and the header was missing the authentication information and therefore this was causing the requests to fail authentication/authorization.  For the life of me I could not figure out what was causing the redirects.

Then I started thinking back to what had changed in the application that may have introduced this behavior.  I had added the use of the SessionAuthenticationModule so that I could store claim information in cookies. This allowed me to keep important information in the claim principal without having to transform it on every request and therefore hitting my back-end database every time.  You can read about adding this valuable feature to your web application in this great article by Dominick Baier.  If you have access to PluralSight I would also recommend viewing Dominick's training course Identity and Access Control in ASP.NET 4.5 which also covers this topic in great detail.

So to find a solution I Googled SessionAuthenticationModule and redirect and came across this article that described my problem to a tee. Apparently this is a known behavior of using the SessionAuthenticationModule.  If you use this module and you use the wrong case for the URL it will redirect back to the same URL using the proper case. And as I pointed out it will leave some header information out of the new web request.  Why they worried about case sensitivity when IIS does not is beyond my comprehension.

So the solution was to fix the case of any URLS in any AJAX calls and any client requests for server resources to match what the web application uses.  Problem solved. I thought this experience was worth repeating since finding this obscure issue can be hard to troubleshoot.


Popular posts from this blog

Customizing Claims for Authorization in ASP.NET Core 2.0

Using Claims in ASP.NET Identity

Adding Email Confirmation to ASP.NET Identity in MVC 5