State – an introduction
September 22, 2010 § 1 Comment
Understanding and being able to properly manipulate state in a web application is crucial to building a functional web application that is performant and scalable. I wonder if the ASP.NET padding oracle attack would have been less of an issue had more people been aware of state and how different options affect performance, scalability, and security. Articles like this one from 4 Guys discussing Forms Authentication that include terms and phrases like “automagically” and “ASP.NET does most of the work from there!” tend to exacerbate the issue:
…One of the new features of ASP.NET is Forms Authentication. Like in classic ASP, where custom database authentication occurred through the user entering his or her login credentials via an HTML form, ASP.NET Forms Authentication works similarly. However, using this neat feature, many of the mundane tasks and code that you were required to write in classic ASP are handled for you automagically.
Forms Authentication in ASP.NET is handled by a special FormsAuthentication class. This class contains a number of static (or Shared) methods that allow you to identify users via a login form. You can easily configure your ASP.NET application to use Forms Authentication by simply specifying a location (URL) for your login form – ASP.NET does most of the work from there! When an unauthenticated user visits a restricted page on your Web site they will be automatically directed to the specified login form. Once they successfully log on, you can optionally issue an authentication cookie to prevent authenticated users from having to log in time and time again….
The thing is that it isn’t “automagic”, though. Understanding that when you save a piece of data it’s going to go somewhere, and knowing where, can make the difference between a barely functioning web app and one that performs well while scaling to meet the needs of however many users you need to throw at it.
One of my favorite interview questions is, “Please talk to me about state and how to manage it in a web application.” The answer to this question tells me a ridiculous amount of information about the interviewee. If they go into a lengthy explanation comparing View State and Session State and continuing on to discuss different options for storing Session State, then we’ll continue with the interview. If they response with a blank state and, “Well, you can store stuff in the session.” then I politely end the interview and get back to work.
So tomorrow, a discussion of View State…