brockallen

I learned something new about ASP.NET today that I had never come across before. I was writing code that looked something like this:

private void CheckForFormsLogout(HttpContext ctx)
{
    if (ctx.User.Identity.IsAuthenticated)
    {
        var logoutCookie = ctx.Response.Cookies[FormsAuthentication.FormsCookieName];
        if (logoutCookie != null)
        {
            var now = DateTime.UtcNow;
            if (DateTime.MinValue < logoutCookie.Expires && logoutCookie.Expires < now)
            {
                // yes, user is logging out
            }
        }
    }
}

Turns out this code has a serious flaw that is actually triggering the logout. The issue is how I was checking for the cookie on the Response.Cookies collection. Turns out that the CookieCollection class creates a cookie if the one you’re asking for doesn’t exist. So in my attempt to see if the cookie was present, I was creating it. The newly created cookie was empty and thus had the side effect of replacing the valid forms authentication cookie with an empty value.

Here’s the change I made to correct the problem:

private void CheckForFormsLogout(HttpContext ctx)
{
    if (ctx.User.Identity.IsAuthenticated)
    {
        if (ctx.Response.Cookies.AllKeys.Contains(FormsAuthentication.FormsCookieName))
        {
            var logoutCookie = ctx.Response.Cookies.Get(FormsAuthentication.FormsCookieName);
            if (logoutCookie != null)
            {
                var now = DateTime.UtcNow;
                if (DateTime.MinValue < logoutCookie.Expires && logoutCookie.Expires < now)
                {
                    // yes the user is logging out
                }
            }
        }
    }
}

The same issue applies to Request.Cookies.

You learn something new every day :)

When using Areas in MVC it’s a common desire to want to use a single layout template for all views. To easily assign a layout template the most common approach is to use a ~/Views/_ViewStart.cshtml (or .vbhtml) in the parent directory of the views. The problem is that when using areas, the ~/Views/_ViewStart.cshtml is not in a parent directory because areas are located in ~/Areas (a sibling of ~/Views). This means the ~/Views/_ViewStart.cshtml is not considered for assigning a default layout template for views within areas.

One solution commonly suggested is to put a _ViewStart.cshtml in the views directory inside the area, but this becomes tedious since you need to do it for each area, as such:

So the obvious approach is to place the _ViewStart.cshtml in the root folder of the entire project. The only problem is that when you create ~/_ViewStart.cshtml and then run the application you end up with this compilation error:

In its wonderful eloquence, this is explaining that you’re using a .cshtml file in MVC and not in WebMatrix. The issue here is that Razor is used in two contexts: 1) MVC and 2) WebMatrix. WebMatrix is the other development framework and tooling under the “One ASP.NET” and it uses Razor as its syntax for mixing markup and code to emit HTML pages dynamically (so in a sense the modern replacement for classic ASP).

So our problem is that we need to tell the ASP.NET compiler to compile this in the context of MVC. This is simple – the same razor configuration that was in ~/Views/web.config simply needs to be moved (or copied) out to the top-level ~/web.config (so the <configSections> and the <system.web.webPages.razor> elements):

And that’s it. You can now have a single ~/_ViewStart.cshtml that assigns a default layout template for all your views (both inside and outside areas).

Oh except for one problem. If you create the top-level ~/_ViewStart.cshtml and run the application prior to copying the configuration values in ~/web.config you might still get the same error from before:

Type ‘ASP._Page__ViewStart_cshtml’ does not inherit from ‘System.Web.WebPages.StartPage’.

The issue here is that once the ~/_ViewStart.chtml has been compiled by the ASP.NET runtime the assembly is cached and not re-compiled when the ~/web.config is changed. The simple fix is to make the changes in ~/web.config and then open and save ~/_ViewStart.chtml. Updating the timestamp on ~/_ViewStart.chtml triggers a recompile but now with the updated settings in ~/web.config.

Here’s a sample project that illustrates this working: http://sdrv.ms/PSTHKk

TempData is a nice feature in MVC and, if I am not mistaken, was inspired by the Flash module from Ruby on Rails. It’s basically a way to maintain some state across a redirect.

In Rails the default implementation uses a cookie to store the data which makes this a fairly lightweight mechanism for passing data from one request to the next. Unfortunately the default implementation of TempData in MVC uses Session State as the backing store which makes it less than ideal. That’s why I wanted to show how to build an implementation that uses a cookie, so here’s the CookieTempDataProvider.

In implementing this it was important to acknowledge that the data stored in TempData is being issued as a cookie to the client, which means it’s open to viewing and modification by the end user. As such, I wanted to add protections from modification and viewing (modification being the more important of the two). The implementation uses the same protection facilities as the ASP.NET machine key mechanisms for encrypting and signing Forms authentication cookies and ViewState. We’re also doing compression since cookies are limited in size.

The code is available on GitHub. I also wrapped this up into a NuGet package (BrockAllen.CookieTempData) so all that’s necessary is to reference the assembly via NuGet and all controllers will now use the Cookie-based TempData provider. If you’re interested in mode details, read on…

The code is fairly self-explanatory:

public class CookieTempDataProvider : ITempDataProvider
{
    const string CookieName = "TempData";

    public void SaveTempData(
        ControllerContext controllerContext,
        IDictionary<string, object> values)
    {
        // convert the temp data dictionary into json
        string value = Serialize(values);
        // compress the json (it really helps)
        var bytes = Compress(value);
        // sign and encrypt the data via the asp.net machine key
        value = Protect(bytes);
        // issue the cookie
        IssueCookie(controllerContext, value);
    }

    public IDictionary<string, object> LoadTempData(
        ControllerContext controllerContext)
    {
        // get the cookie
        var value = GetCookieValue(controllerContext);
        // verify and decrypt the value via the asp.net machine key
        var bytes = Unprotect(value);
        // decompress to json
        value = Decompress(bytes);
        // convert the json back to a dictionary
        return Deserialize(value);
    }
    string GetCookieValue(ControllerContext controllerContext)
    {
        HttpCookie c = controllerContext.HttpContext.Request.Cookies[CookieName];
        if (c != null)
        {
            return c.Value;
        }
        return null;
    }

    void IssueCookie(ControllerContext controllerContext, string value)
    {
        HttpCookie c = new HttpCookie(CookieName, value)
        {
            // don't allow javascript access to the cookie
            HttpOnly = true,
            // set the path so other apps on the same server don't see the cookie
            Path = controllerContext.HttpContext.Request.ApplicationPath,
            // ideally we're always going over SSL, but be flexible for non-SSL apps
            Secure = controllerContext.HttpContext.Request.IsSecureConnection
        };

        if (value == null)
        {
            // if we have no data then issue an expired cookie to clear the cookie
            c.Expires = DateTime.Now.AddMonths(-1);
        }

        if (value != null || controllerContext.HttpContext.Request.Cookies[CookieName] != null)
        {
            // if we have data, then issue the cookie
            // also, if the request has a cookie then we need to issue the cookie
            // which might act as a means to clear the cookie 
            controllerContext.HttpContext.Response.Cookies.Add(c);
        }
    }

    string Protect(byte[] data)
    {
        if (data == null || data.Length == 0) return null;

        return MachineKey.Encode(data, MachineKeyProtection.All);
    }

    byte[] Unprotect(string value)
    {
        if (String.IsNullOrWhiteSpace(value)) return null;

        return MachineKey.Decode(value, MachineKeyProtection.All);
    }

    byte[] Compress(string value)
    {
        if (value == null) return null;

        var data = Encoding.UTF8.GetBytes(value);
        using (var input = new MemoryStream(data))
        {
            using (var output = new MemoryStream())
            {
                using (Stream cs = new DeflateStream(output, CompressionMode.Compress))
                {
                    input.CopyTo(cs);
                }

                return output.ToArray();
            }
        }
    }

    string Decompress(byte[] data)
    {
        if (data == null || data.Length == 0) return null;

        using (var input = new MemoryStream(data))
        {
            using (var output = new MemoryStream())
            {
                using (Stream cs = new DeflateStream(input, CompressionMode.Decompress))
                {
                    cs.CopyTo(output);
                }

                var result = output.ToArray();
                return Encoding.UTF8.GetString(result);
            }
        }
    }

    string Serialize(IDictionary<string, object> data)
    {
        if (data == null || data.Keys.Count == 0) return null;

        JavaScriptSerializer ser = new JavaScriptSerializer();
        return ser.Serialize(data);
    }

    IDictionary<string, object> Deserialize(string data)
    {
        if (String.IsNullOrWhiteSpace(data)) return null;

        JavaScriptSerializer ser = new JavaScriptSerializer();
        return ser.Deserialize<IDictionary<string, object>>(data);
    }
}

Normally to use a custom TempDataProvider you must override CreateTempDataProvider from the Controller base class as such:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }

    protected override ITempDataProvider CreateTempDataProvider()
    {
        return new CookieTempDataProvider();
    }
}

Ick — this means you either have to override this in each controller or have to have planned ahead and created a common base Controller class for the entire application. Fortunately there’s another way — the TempDataProvider is assignable on the Controller base class. This means that upon controller creation you can assign it and this can easily be done in a custom controller factory which I implemented in the NuGet package:

class CookieTempDataControllerFactory : IControllerFactory
{
    IControllerFactory _inner;
    public CookieTempDataControllerFactory(IControllerFactory inner)
    {
        _inner = inner;
    }

    public IController CreateController(RequestContext requestContext, string controllerName)
    {
        // pass-thru to the normal factory
        var controllerInterface = _inner.CreateController(requestContext, controllerName);
        var controller = controllerInterface as Controller;
        if (controller != null)
        {
            // if we get a MVC controller then add the cookie-based tempdata provider
            controller.TempDataProvider = new CookieTempDataProvider();
        }
        return controller;
    }

    public SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName)
    {
        return _inner.GetControllerSessionBehavior(requestContext, controllerName);
    }

    public void ReleaseController(IController controller)
    {
        _inner.ReleaseController(controller);
    }
}

The last thing is to configure the custom controller factory, and from a separate assembly this was done via the magic of PreApplicationStartMethod which allows for code to run prior to Applicaton_Start:

[assembly: PreApplicationStartMethod(typeof(BrockAllen.CookieTempData.AppStart), "Start")]

namespace BrockAllen.CookieTempData
{
    public class AppStart
    {
        public static void Start()
        {
            var currentFactory = ControllerBuilder.Current.GetControllerFactory();
            ControllerBuilder.Current.SetControllerFactory(new CookieTempDataControllerFactory(currentFactory));
        }
    }
}

Anyway, that’s it. Feedback is always welcome.

Given that I just did a webcast on mobile support in MVC 4, I thought it fitting to discuss how essentially the same mobile support can be achieved today in MVC 3. In a fairly simple way we can build a similar framework to what will be provided in the next version.

I want these requirements (which are comparable to what we get in MVC 4):

1. I don’t want a controller action to have to fret about what view to deliver based upon the client device (mobile vs. non-mobile).
2. I want a mobile view to be delivered if there is a view that conforms to a particular naming convention (such as Index.Mobile.cshtml).
3. I only want a render the mobile view if the client device is a mobile device (this one is sort obvious).

To alleviate the controller of the logic to decide if a mobile view should be rendered or not we will develop an action filter. This allows common functionality to extracted into one location yet applied to multiple controllers and actions.

To dynamically discover if we have a mobile version of a view we’ll have to ask the MVC plumbing a few questions, but it’s not difficult.

To know if the current request is from a mobile device, we’ll simply ask ASP.NET :)

Here’s the action filter:

public class MobileAttribute : ActionFilterAttribute
{
    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
        // is the request a view and is the client device a mobile device
        var vr = filterContext.Result as ViewResult;
        if (vr != null &&
            filterContext.HttpContext.Request.Browser.IsMobileDevice)
        {
            // determine from the current view what the mobile view name would be
            var viewName = vr.ViewName;
            if (String.IsNullOrWhiteSpace(viewName)) viewName = (string)filterContext.RouteData.Values["action"];
            var fileExtension = Path.GetExtension(viewName);
            var mobileViewName = Path.ChangeExtension(viewName, "Mobile" + fileExtension);

            // ask MVC is we have that view
            var ver = ViewEngines.Engines.FindView(filterContext, mobileViewName, vr.MasterName);
            if (ver != null && ver.View != null)
            {
                ver.ViewEngine.ReleaseView(filterContext, ver.View);

                // we do, so tell MVC to use the mobile view instead
                vr.ViewName = mobileViewName;
            }
        }
    }
}

And here’s the action filter applied to a controller:

[Mobile]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

Of course, this could also be applied globally in the MVC application.

So this shows: 1) How easy it is to have mobile support in MVC versions prior to MVC4, and 2) How powerful action filters are at providing interception into the MVC framework.

Sample code here.

So this question comes up all the time: “Where should I keep my shopping cart data for my application?” The common knee-jerk response is “use session state”. I find this to typically be the wrong answer if you want to build a resilient and scalable application.

Session state was originally meant for this kind of data (user provided data like a shopping cart). One thing session is not meant for is caching of user profile data. Back in classic ASP there were not a lot of other caching per-user data, so session was the obvious choice, but in ASP.NET (and just .NET in general) there are so many better options. One such example is the data cache in ASP.NET. With the data cache you specifically code to deal with failure (the cache item might not be present) and you can also set very specific conditions per cache item designating how long you’d like the cache the item. The data cache is very useful for a place to store data when you want to avoid round trips tot he database. But why not use session? Wouldn’t be essentially the same since it is also stored in-memory? Read on…

So back to session state as a place to store user driven data (i.e. shopping cart)… Session state is stored in-memory by default. This is a horrible option if you want to remember data for your users. In ASP.NET the hosting application pool frequently recycles and this is typically out of your control. This means that all that in-memory state is lost, which is why using session state in-proc is a bad choice. If you’re going to the effort to keep this data for the users, you simply can’t rely upon in-memory state — think shopping cart which equates to making sales on your website or simply the frustration of your users when all their data is lost and you have to make them start all of their shopping over again.

As an alternative you can store your session out-of-proc (in the ASP.NET State Service which is a windows service or in SQL Server or in a custom store). This certainly makes the state more resilient, but there is a cost to this resiliency. Each HTTP request into the application means that your application must make 2 extra network requests to the out-of-proc store — one to load session before the request is processed and another to store the session back after the request is done processing. This is a fairly heavy-weight request as well because the state being loaded is the entire state for the user for the entire application. In other words if you have ten pages in your application and each one puts a little bit of data into session, when you visit “page1” then you’re loading all of the session data for “page1”, “page2”, “page3”, etc. By the way, these extra network requests happen on every page even if you’re not using session on the page. There are some optimizations (EnableSessionState on the Page and SessionStateAttribute for MVC), but they don’t solve the problem entirely because the network request must happen to update the store to let it know the user is still active so that it doesn’t cleanup inactive sessions.

So back to caching briefly: this is why we prefer to use the data cache for caching and not session. If you’re using session for any user generated data, then you can’t keep it in-proc and you should keep it out-of-proc and once it’s out-of-proc then that defeats the purpose of caching. The data cache is for read-only data that can be reloaded from the original data source when the cache expires and session is meant for user driven data like shopping carts. Except session has all these problems…

So what to do for our shopping cart data? Here’s what I suggest: 1) explicitly disable session in your application’s web.config (it’s enabled by default in the machine-wide web.config), 2) keep the user data elsewhere. Elsewhere might mean in a cookie, in a hidden field, in the query string, in web storage or in the database (relational or NoSQL). Which one’s the right answer? As always, it depends. For shopping cart like data, I’d probably use the database. I’d create a custom “shopping cart” table and as users add items then you make network call to update the database. Once the user places the order then you’d clear out rows for the user’s shopping cart. As for the key in the shopping cart table you can simply use the user’s unique authentication username from User.Identity.Name.

So the complaints about my conclusion are: 1) effort, 2) network calls, 3) abandoned shopping carts and 4) what about anonymous users.

1) Some people complain that this is too much work. I’m sorry to inform you that programming is hard. Get over it. And to be honest, it’s not that hard with the modern ORMs we have of if you’re using a NoSQL database then it’s even easier. Also, this database doesn’t have to be your main production database — it could just be a database that’s for the webserver.

2) What about all these network calls? Well, if you were using session then in-proc was a non-starter and you were going to have to keep this data out-of-proc. So you were already going to incur heavy-weight network calls. With this approach only the pages that need the shopping cart data incur the network calls and the pages that don’t need the shopping cart data won’t have this burden imposed upon them. This is already better than out-of-proc session.

3) With this approach you will need to have some way to periodically cleanup abandoned shopping carts. Sure, but the application is still better off for the effort. Also, this assumes that you do want to get rid of the data, but think about amazon — they don’t ever want to get rid of shopping cart data. That data is potential sales (they remind you on every visit that you forgot to give them your money) and it’s probably useful for data mining. So maybe keeping this data is a good thing.

4) I suggest that you should use the authenticated user’s username for the key in the shopping cart table. Well, what about anonymous users? Part of the Session feature is that there is a “Session ID” associated with the user and this is sometimes quite useful. It is, but not at the expense of at of the other parts of session. So what to do? Well, there’s a little known feature in ASP.NET called the Anonymous Identification Module. This is a HttpModule whose sole purpose is to track anonymous users with an ID. If you enable this feature, then it issues a cookie with a unique ID per anonymous users. You can then access that ID in your code via Request.AnonymousID.

One last reason session is problematic: concurrent requests. Access to session (by default) is exclusive. This means that if your page makes 2 Ajax calls back to the server, ASP.NET forces one to wait while the other executes because each request is taking locks on the session. This really hampers scalability if not responsiveness. Also, with some of the new HTML5 features like Server Sent events that hold long-lived connections to the server then this can lock a user out of the server if they try to make a request at the same time.

So beware anytime someone says “use session state — it’s easy”. If something’s easy then you’re making a tradeoff. Realize what you’re trading off and just take a minute to think about a better way to store the data. Your application will be better off.

If you’ve ever been to one of my ASP.NET or MVC classes then you’ve heard this before. For those that haven’t, I’ve been meaning to write this since 2006… better late than never.

Recently a poster on the asp.net forums asked about the difference between returning HTML or JSON from Ajax calls. Here was my answer:

airic82

Well, ya. But working doesn’t always mean its following best practices.

Sinful term! “Best practice” requires context. Usually the answer is “it depends” and thus there’s rarely “the one and only one best practice” which is what people are usually looking for.

airic82

I guess the piece I’m missing is the difference between returning HTML and JSON. Maybe there really isn’t any difference, but I’d think there was since we can specify a difference. Thanks for your help, man!

Ah, ok… so yes, there’s a difference there. If your Ajax call returns HTML this means you’ve done the UI “work” (so to speak) on the server (using WebForms, Razor, whatever) and then that HTML is returned to the browser and merged into the DOM (and merged into the DOM in one place). This might work fine, but sometimes things are more complex and this is where returning JSON might make more sense.

Returning JSON means the UI “work” (rendering) is done in JavaScript/jQuery client-side. The network bandwith is much less (JSON is more compact than HTML [or XML for that matter]). But the downside is this requires more JavaScript to do the rendering (but less server side coding). Returning JSON and thus allowing the JavaScript to build the UI from the result also allows for more complex UIs — imagine where the results means you have to update multiple elements. That’s hard to do if your’e returning a single block of HTML from the server. With JSON the client-side JavaScript can use that JSON data to update multiple parts of the UI. Also, if the client is a mobile device then it’s preferred that you return JSON as to minimize bandwith to save battery on the device.

Anyway, the answer is “it depends” — that’s the consulting answer :)

Edit: The Assets feature was removed from the RTM in favor of bundling and minification.

In MVC4 they’ve added an API to centralize script and style sheet includes when rendering a complex view with partials and a layout template.
The problem is a single view might have many partials that all need the same script or style sheet. How do they “know” that the script or style sheet they depend upon is included and only once? Previously, that was up to the developer coordinating the views, partials and layout template in MVC to come up with a solution.
Now with MVC4 the Assets API provides a way for a view or a partial to indicate they require a script and for a layout template to indicate where those scripts and style sheets should be rendered:

public static class Assets
{
public static void AddScript(string scriptPath);
public static void AddScriptBlock(string block);
public static void AddScriptBlock(string block, bool addScriptTags);
public static void AddStyle(string cssPath);
public static void AddStyleBlock(string block);
public static void AddStyleBlock(string block, bool addStyleTags);
public static IHtmlString GetScripts();
public static IHtmlString GetStyles();
}

Now a partial can indicate a script or style sheet to include:

@{
Assets.AddScript("~/Scripts/jquery-1.7.1.js");
Assets.AddStyle("~/Content/Foo.css");
}
<h2>Some Partial</h2>

And the layout template can render those assets:

<!DOCTYPE html>
<html>
<head>
@Assets.GetStyles()
</head>
<body>
@RenderBody()
@Assets.GetScripts()
</body>
</html>

In MVC4 we now have display modes. This allows view engines to somewhat encapsulate the selection of alternative views based upon some criteria (typically some aspect of the request like the User-Agent HTTP header). This is intended to be how MVC supports different rendering for mobile devices.

The default display mode will render “.Mobile” views, partials and layout templates if the client device is a mobile browser. There is also an API to override this behavior: HttpContext.SetOverriddenBrowser. This allows you to ignore the User-Agent header for a user and pretend they are using some other device. This is typically done for mobile users that desire the “normal” desktop version of the website instead of the mobile version.

The way you check for this overridden User-Agent or HttpBrowserCapabilities is to call: HttpContext.GetOverriddenUserAgent or HttpContext.GetOverriddenBrowser. This pair of methods will return the overridden value or the normal value if there is no override. When I first saw this behavior I was a little upset because there’s no API to determine if we’re currently in override mode or not.

I suppose the only way around this is to call Request.UserAgent or Request.Browser to check the actual device’s values.

If you’re ~/bin deploying MVC (or more specifically “ASP.NET Web Pages with Razor syntax”) and you’re having a problem with your login URL redirects (with FormsAuthentication or WIF for that matter) then let me help you. Prior to ~/bin deployment your login redirects were working fine. You’d go to some URL and you’d get redirected to your custom login page as configured in web.config, such as this (note the non-standard loginUrl):

<authentication mode="Forms">
<forms loginUrl="~/Account/Auth/Login"/>
</authentication>

But now that you’ve ~/bin deployed MVC anytime you are redirected to a login page it’s this URL instead (note the URL is different than the one configured above):

~/Account/Login?ReturnUrl=the-path-you-were-not-authorized-for

Dominick just had this problem earlier today (but since it wasn’t my problem at the time I didn’t help him out… sorry Dom). Coincidentally I ran into the same issue later in the same day (and since it was now my problem I spent the time to look into it) . Anyway, to solve the problem you need to disable something called “simple membership”. To fix go into web.config and add this:

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

And now you should be all set. If you want to know what the underlying problem is read on.

What’s happening is that when you ~/bin deploy MVC and Razor, the Razor DLLs are auto-registering some pre-App_Start code to run (which I thought was a neat idea, until now). For the curious it’s WebMatrix.WebData.PreApplicationStartCode.SetupFormsAuthentication from WebMatrix.WebData.dll. If this assembly is not ~/bin deployed then this pre-App_Start code doesn’t run. This pre-App_Start code will force Forms authentication to be enabled (with the login URL at the aforementioned path) unless it finds config data telling it otherwise. Here’s the kicker: the absence of any config data is sufficient to enable this feature. You have to explicitly disable it (as described above). This is quite annoying.

Sir Haack, plz fix (or make the VS tooling add this to the .config when you add deployable dependencies).

Edit: The way to avoid all of this is to simply not check “ASP.NET Web Pages with Razor syntax” (even though it’s quite tempting given the name) when ~/bin deploying. Phil did mention this in his post on the topic, but that detail escaped me when I was doing this in VS. Thx for the followup Phil.

Edit 2: Also seems there’s a .config setting to be able to use simple membership but to keep the login page controlled by your app:

<appSettings>
    <add key="PreserveLoginUrl" value="true" />
</appSettings>