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.