Book Review of Maximizing ASP.NET by Jeffrey Putz
I've never read a full sized technical book from cover to cover in under a week until I picked up Maximizing ASP.NET. I couldn't put it down, every lunch break and into the wee hours of the morning I took every opportunity I could to consume this book.
Not only was the subject matter exactly what I have been searching for the last couple of years, but Jeff Putz covered this topic with expertise, great code examples and just plain great writing.
I've come from a Classic ASP and PHP background so, although I use ASP.NET daily from an administrative level, I haven't felt that I had a full grasp of Object-Oriented (OO) development. Over time I've picked up more and more but I've been searching for a good book to piece it all together and fill in the blanks. I've read bits and pieces from other books and understood the concepts of OO programming but I wanted to know from an ASP.NET perspective.
Putz's book is well balanced and jumps right into OO development, the concepts and specifically how they relate to ASP.NET. Both C# and VB code examples are generous, clear and concise. I've read plenty of books where some of the chapters are worth reading but many others were better left out. Not with Maximizing ASP.NET. Every chapter is a must read. There were a couple sections about the HTTPModules and HTTPHandlers that I found better reference material than reading word for word, but even then I couldn't put the book down.
Another thing I appreciate about this book is that it is organized in a way that makes it a great reference book. Finding information again is quick and easy whether from using the Index at the back, skimming the well organized Table of Contents at the front or flipping to the highlighted sections that I marked up when reading the book the first time.
Like any book, this one isn't for everyone. Putz assumes that the reader has a general understanding of ASP.NET and web development already and doesn't spend time covering the basics. While I found this enhanced the book and allowed him to jump right into his intended subject matter, a newbie to ASP.Net would not want this as their first book. That said, this is a easy to read book and is great for anyone's library after an ASP.NET foundation has been laid.
I can't say enough how much I appreciated Maximizing ASP.NET, in fact before I even finished reading the book I had ordered a half dozen copies of the book for people I thought would benefit from it. I highly recommend this book to anyone that is serious about OO programming and wants a thorough, accurate and easy to read resource.
One of the first things many people try with ASP.NET V2.0 (currently in Beta 2) and with the starter kits is to create a new user. Whether it is the CreateUserWizard, a starter kit form or using the membership namespace from code, creating a new profile is going to happen. Immediately following that is often a sigh of frustration when a fairly non-descriptive error occurs: "Please enter a different password." What is that supposed to mean? Is it recommending passwords for us now and not pleased with the one we chose? Did the passwords not match? Even carefully double checking and trying again with a password that is 7 characters and has numbers and upper case and lower case letters triggers this non-descriptive error.
The issue is simply this: ASP.NET V2.0, at the time of writing, has a password complexity requirement of 7 characters and at last 1 non-alphanumeric character. For example, 'Complex592PaSsWoRd' isn't complex enough. A space or a special character is required. Now, being cautious about security is one thing, but many of the V2.0 sites out there now are either test sites, personal or club starter kits or something fairly light. Personally I like to loosen the requirements somewhat, or even loosen them a lot and allow the user to determine how complex they want their password.
Fortunately there are a couple solutions and neither are too complex. The first solution obviously is to enter a more complex password. The second is to override the default complexity requirement and put in your own.
The provider that controls this is the membership provider. This is set by default in the machine.config file on the server. It can be changed at the machine.config file or overridden in the web.config file at the site level.
The two properties that control this are minRequiredPasswordLength and minRequiredNonalphanumericCharacters. They aren't in machine.config by default in the Beta 2 timeframe. I'm not sure if there are plans to change this or not. To override it, simply add them to the <add name="AspNetSqlMembershipProvider" /> section. The minRequiredPasswordLength property must be at least 1, while the minReqiredNonalphanumericCharacters property can be 0. Here is an example of the two lines to add which removes the requirements completely and allows the user to decide on their password. Don't hold me accountable if you open this too much, but I give this example as the other extreme of the default settings.
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
Now, let's say we want to do this at the web.config level. This is easy enough too. The gotcha is that because it already exists at the machine.config level, there will be a clash between the two. So, you must first "remove" the provider set at the machine level and add it back at the site level. To remove the existing one, (I'm assuming default names) you use <remove name="AspNetSqlMembershipProvider" />
Here is an example of a complete web.config file that could be used. If you have an existing web.config file that you want to work this into, take the section between and including <membership> and </membership> and place it in your <system.web> section.
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<connectionStrings>
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer" connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|aspnetdb.mdf" />
</connectionStrings>
<system.web>
<membership>
<providers>
<remove name="AspNetSqlMembershipProvider" />
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="LocalSqlServer"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="/"
requiresUniqueEmail="false"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
passwordAttemptWindow="10"
passwordStrengthRegularExpression="" />
</providers>
</membership>
</system.web>
</configuration>
Of course anything in my example can be adjusted however you want as long as it is within an allowed range. Take note especially of the connectionStringName which is referenced in the ConnectionString section of web.config and/or machine.config. If you changed your connection string name, then make sure to update the reference to that connection string there. Another thing to take note of is the connection string in this example. That connection string will only work if Sql Server Express is installed on the server and "user instancing" is enabled. At ORCS Web (www.orcsweb.com) for example, we disable user instancing because of security considerations, create a database when first setting up the site, and provide an alternative connection string which should be used instead.
That's it. Once you set this, you'll be able to have a password that isn't quite so complex. This quick example only briefly covers other considerations like the connectionStringName, user instancing, type of database used and additional properties but I hope it gives enough information to lay the foundation of managing the password complexity within ASP.NET v2.0.