ASP.NET Remember Me Functionality

I deployed a new ASP.NET web application a couple of months back. When I set it up in Visual Studio, I used the individual user accounts option for authentication. The login screen that is included in the generated project includes a “Remember Me” checkbox. I would typically use the application once per day, but I noticed that even though I checked the “Remember Me” checkbox, my credentials would be forgotten the next day.

Heading in, I did not know much of anything about how the various ASP.NET MVC authentication options worked. It turns out the the individual user accounts option results in ASP.NET Identity being used. ASP.NET Identity makes use of OWIN. This option is not the same as Forms Authentication, which is an older technology. I assumed that was what was actually being used, so this was a surprise to me.

After doing some research on my issue, I discovered that the default timeout for ASP.NET Identity with the “Remember Me” option was 14 days. Once I dug deeper, I found that I had a .AspNet.ApplicationCookie cookie with an expiration date that was set 14 days out. However, even with that cookie, my browser would seem to forget the login.

How should “Remember Me” work? If you login without “Remember Me” checked, close your browser, and reopen your browser, it will forget you. If you login with “Remember Me” checked, close your browser, and reopen your browser, it will remember you. The problem for me was occurring if I would leave the browser closed for more than 20 minutes.

During my research, I read that several issues had been fixed in ASP.NET Identity 2.2. I was using 2.1, so I tried upgrading. Unfortunately, that also did not make a difference. At least having the newer version did not result in any additional negative impacts for me.

I did some testing locally, and I noticed that the behavior was different. The browser would still remember me after the 20 minute timeframe had passed. This definitely made me curious regarding whether there was something in the hosting environment that was causing me problems. I did compare the web.config file for both environments and found no relevant differences.

After running through a number of test scenarios, I decided to post a question to Stack Overflow. Someone there mentioned that it may be related to the application pool idle timeout. I am the only person currently using the application, so it is very susceptible to idle timeouts. After consulting with my hosting provider, I found that they do not allow that setting to be modified. Instead, I ended up setting up a scheduled task with the hosting provider to ping the web site and keep the activity going. After that, I was finally seeing the browser maintain my credentials after the 20 minute time period.

Admittedly, this was not the solution that I would have hoped for. If I ever move hosting providers, I will need to setup a similar solution there. However, it was beneficial for me to have the problem, as it afforded me to learn a little bit about how the default ASP.NET MVC authentication setup works. I’m looking forward to digging into it further in the future.

Third Party View Engines R.I.P?

After finishing my recent overview of ASP.NET MVC view engines, I thought that I would take a deeper look at a specific third party view engine implementation. The users of Stack Overflow have provided a good list of available view engines. I took a brief look at the web sites for all of the view engines, and one thing that really stuck out at me was the fact that none of them had been updated for quite some time.

Despite this, I decided that I would experiment one of them, and chose NHaml. Based on the Rails Haml view engine, NHaml sounds intriguing to me. It takes a different approach than most by abstracting away the HTML markup language.

I saw that a NuGet package was available for NHaml, so i figured that chances for getting it running were promising. Unfortunately, after fiddling around with it for a while, I did not have good luck getting it running under MVC5. I managed to get around the initial error with the NuGet package (Derived types must either match the security accessibility of the base type or be less accessible) by downloading the source code and removing the “AllowPartiallyTrustedCallers” attribute from the SharedAssemblyInfo.cs in the System.Web.NHaml project. However, I then found myself running into access denied errors as NHaml apparently tries to delete temp files from disk.

Considering that NHaml has not been updated for quite some time, I decided that it wasn’t worth investing anymore time into getting it up and running. I may still take a look at one of the other view engines, just to get a sense for how different it is from Razor.

I do still wonder why there has been no recent action on the third party view engine front. I don’t have any complaints about Razor, but is it really that good that it deserves no well maintained competition other than the ASPX view engine? Apparently, Microsoft has done a good job of meeting the desires of developers with the feature set that they have provided in Razor.