Several sites exist out there that urge developers to think about what they’re doing and they range from the architectural perspective (codebetter.com) to the human factors perspective (codinghorror.com — an excellent site that never disappoints.)

Regardless of the reason, it appears to me that a fundamental piece of the puzzle is missing. That piece being coding better isn’t the same thing as coding smarter. It appears to me that some developers have a unique form of savant syndrome granting them all the architectural prowess for which one could ever hope but none of the common sense development practices that can actually make or break an application.

I’m an excellent developer.
 

Let’s take the following scenario that, sadly, is one of four from an application I inherited.

The first scenario in “Coding Smarter” involves understanding your medium. By that, I mean that you should really understand how the technology you’re using functions.

This application wanted to maintain a user id once the user was logged in. I wrote about an expansion of this method on Stackoverflow.

The general idea is that you want to maintain as little (or as much, sadly) state as you can between requests and given that HTTP is a stateless protocol you need to store it somewhere. Typically this information is stored in the session on the server but the authors of the application didn’t deem the session worthy and decided that they would store the user id of the user making the request in… wait for it… the ViewState.

 

Think about this for a second. What do we know about the ViewState?

Well, for starters, the ViewState is sent back and forth between the server and the client. This means that for every item that is stored in the ViewState, that item must be returned from the client to the server with every request. (Incidentally, they also made liberal use of UpdatePanel). This might be “OK” — not really, but wait for it — because the user id is only an integer, but this application stored EVERYTHING in the ViewState that it needed. No use of session variables were involved.

The BIGGER issue with storing the user id in the ViewState is that it is not secure. ViewState is not encrypted by default, merely encoded. Not surprisingly, there was no encrypting of the ViewState taking place in the code so anyone that could access it could decode it.

In the developer’s defense, they did encrypt the individual fields that were going into the ViewState, but unless they were encrypting them properly they may as well not have encrypted them at all.

The BIGGEST problem is that there is, essentially, no user authentication timeout. That means that the user can be using the site, step away from the computer for a week, a month, even a year, and then come back and continue on their merry way on the site. Or, go about browsing other sites, hit back in their browser to load a page from the site (there was also no client-side cache expiration), perform some new action and automatically be logged into the site. This might be fine on a site that’s not handling sensitive information. Unfortunately, this site is.

The lesson is that just because a framework or platform makes something available to you doesn’t mean that you have to use it. If you want to use it, make sure you understand what it is, how it functions, and what the repercussions of using it actually are.

I’m debating on turning this into a series given the number of issues I typically stumble upon when inheriting projects. If you would like to see more of this, let me know.

For those of you familiar with ASP.NET 2.0, you know that if you want to find the root of the application, you use Server.MapPath.  Turns out the the root directory (~/) and the bin directory (~/bin — typically) are the same as the parent site.  This means that if your sub-site needs to read information from the web.config then you can store it in the web.config of the parent application.

There is one downside to this.  If you have multiple instances of the same site definition within the same web application, there is no way to separate values within the web.config.  As an example, assume you need to email an administrator when a site experiences a problem but the administrator is different for each subsite.  This information cannot be stored in the web.config as both subsites in the site collection will share the configuration.

This may not be news to some, but without years of SharePoint/WSS experience I found this important to share.

The problem occurs with how ASP.NET tells the client to retrieve embedded resources. Embedded resources are typically returned to the web client by a call to WebResource.axd that exists in the application root (~/) — the file’s not actually there, it’s a handler. From the ASP.NET application’s perspective, ~/ maps to /someapp. However, the web client is assuming that the application root is / because they’re looking at the pages through the reverse proxy, a proxy of which ASP.NET is blissfully unaware.

As stated earlier, the true application root is /someapp and ASP.NET tells the client to access WebResource.axd at /someapp/WebResource.axd. The web client assumes that this is appended to the current root which is http://somecompany.com/ and then tries to retrieve WebResource.axd at http://somecompany.com/someapp/WebResource.axd, a location that the proxy then maps to http://somehost.com/someapp/someapp/WebResource.axd. This isn’t accounted for in the http handler’s mapping and the request returns a 404.

The 404 File Not Found code is problematic in that WebResource.axd is the handler responsible for returning all of the embedded resources in the application — typically JavaScript for ASP.NET user controls, ASP.NET validation controls, and 3rd party controls. The application breaks and it’s bad times for all. Enter UrlRewritingNet.UrlRewrite.

This free open source library will allow rewrites to be performed simply by adding a couple entries in the application’s web.config and including the library in the application’s bin folder. This is perfect for shared hosting environments where access to the actual server to install isapi rewrite is not possible.

The documentation is pretty clear, though the English is a bit broken, and contains the enumerated steps for installation into the application. Once the library has been installed, all that’s left is to write some simple rewrite rules.

Inside the web.config, for this application, we would add the following rewrite rules

<urlrewritingnet xmlns="http://www.urlrewriting.net/schemas/config/2006/07" >
<rewrites>
<add name="WebResourceFix" virtualUrl="^~/WebResource.axd(.*)" rewriteUrlParameter="IncludeQueryStringForRewrite" destinationUrl="~/WebResource.axd$1" ignoreCase="true"/>
<add name="ScriptResource" virtualUrl="^~/(.*)/ScriptResource.axd(.*)" rewriteUrlParameter="IncludeQueryStringForRewrite" destinationUrl="~/ScriptResource.axd$2" ignoreCase="true"/>
<add name="ReplaceRoot" virtualUrl="^~/(.*)/(.*)" rewriteUrlParameter="IncludeQueryStringForRewrite" destinationUrl="~/$2" ignoreCase="true"/>
</rewrites>
</urlrewritingnet>

This rewrite rule will take any inbound request to /someapp/WebResource.axd and map it to /WebResource.axd. This ends the 404 and its good times for all.

So far, I’ve had nothing but success with this approach and have extended it to handle the ASP.NET Ajax resource tool ScriptResource.axd that suffers from the same fate. Additionally, if Web Service callbacks are used in the application for Ajax invocation, the same rules will need to be applied to the page and it may be easier to simply remap anything that comes in for /someapp to /.
Note, there are other methods that will allow you to fix some of these issues, but they’re not always achievable in shared hosting environments or in environments where configuration is tightly controlled. Further, this does not handle problems with using web.sitemap in an application that is behind a reverse proxy but that will be left as an exercise to the reader.