Snow Leopard has only been out since Friday, but a few people got the OS upgrade early and blogged all the good stuff. Knowing this, I'm still going to blog about the new OS from Apple.

Error Readout:
Exception: System.Web.HttpException
Message: Authentication of viewstate failed.  1) If this is a cluster, edit configuration so all servers use the same validationKey and validation algorithm.  AutoGenerate cannot be used in a cluster.  2) Viewstate can only be posted back to the same page.  3) The viewstate for this page might be corrupted.
Source: System.Web
   at System.Web.UI.LosFormatter.Deserialize(String input)
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()


Fix:
I encountered the above error the other day. Since the server wasn't on a web farm I was a little confused. The fix I ended up using was updating the web.config key to

requiressl=true


Explanation:
The next thing I asked myself was how can that key affect the viewstate. With some serious investigation into viewstate and best practices I finally made the link of how our applications viewstate is tied to session state which is tied to SSL when the session cookies are encrypted manually, a step (encrypting our own session cookies manually) we did because we are still running asp.net 1.1.

In .net 1.1 there is a property called "ViewStateUserKey" located in the viewstate, this key adds user-specific information to the view state. When the request is processed, ASP.NET extracts the key from the view state and compares it against the ViewStateUserKey of the running page. If the two match, the request is considered legitimate; otherwise an exception is thrown. In our application we use the Session.SessionID to set the property. This is where my problem starts.

When a user fills out a form utilizing viewstate to create an account to login to our system the user establishes a viewstate in their asp.net page.  In order to make the view state slightly more secure we give the viewstateuserkey the same value as the session ID. The session ID is a much better fit because a session ID is unpredictable, times out, and varies on a per-user basis
[http://msdn.microsoft.com/en-us/library/ms972969.aspx]

Once the user has completely filled out the form, we authenticate them.  This is where my error occurs [See beginning of post].


The error is caused because the session id is now encrypted. It's encrypted because our security team said, all information stored in cookies is to be secured. Our team consequently set up a flag in the global.asax file that states if this flag is set to true it should grab the session id out of each cookie and encrypt it. The reason we did this by hand is because asp.net 1.1 does not offer secure cookies with one easy key change in the web.config [NOTE: In asp.net 2.0 all you have to do is have the requiressl=true and you are done].

Now understanding that our session ID is tied to our viewstateuserkey you can understand the viewstateuserkey is now invalid because the session ID is a different value, simply because it's encrypted and the server does not know to decrypt it.  [NOTE: The session ID may still be the same value, it's just encrypted.] Now asp.net states the viewstateuserkey is invalid and pumps out the error you have seen above.

To fix this I simply change requiressl=true in the web.config.  How does requrie ssl affect an encrypted session id within a cookie that I set to encrypt? Well, when requiressl is not on but you are sending the server a secure cookie value, which we did since we created our own secure cookies in asp.net 1.1  the server doesn't know to decrypt the cookie because requiressl is not turned on [apparently you have to send secure cookies over ssl in asp.net 1.1 and possibly other run times, I didn't know this] which in turn invalidates the viewstateuserkey because the viewstateuserkey uses the session ID which is encrypted in the secure cookie.

What made this confusing for me is the first part of the form worked without a hitch. It's when the user authenticates when the error arose. The reason for this being that the requiressl key is not applicable until authentication happens. If you'll notice the requiressl key is nested in the authentication element in the web.config file.  Additionally we don't encrypt the cookie until the user is authenticated.  Sooo, the first few postbacks for our page were just collecting information.  It wasn't until we authenticated the user to our system that requiressl actually cared if we had secure cookies or not.


Overview
Viewstateuserkey is set to the session ID.

Session ID is encrypted and the updated value is set to the viewstateuserkey

requressl being turned on tells the server to decrypt session id in which case allows the viewstateuserkey to remain valid with the server.

So basically IE 7 is just bad. We all knew it, but this is just one aspect that confirms it.

My boss and co-worker dealt with the error last week. IE7 on the third request to a web server would fail. No real good reason, it just would. Now being a Mac guy this just fueled my fire. I hate errors that just happen, with no real good explanation behind it and by no good explanation I mean IE7 should just work, and not be breaking on a simple web request.

To top it all off we are a website that sees millions of sessions a month. Call center = not happy. Also noting there are more people using IE7 then I would have ever expected. Really people IE7?

My co-worker James Peckham blogged the issue and resolution already so I'll just quote and post a link.  Thanks for the leg work James.

"So I saw this awesome issue where IE 7 hangs indefinitely and stops responding on the third request for a page. Yes the 3rd request.

Basically IE7 is limited to 2 active connections per server inside one browser window (including all tabs) and these connections were being wasted in unresponsive requests for favicon.ico.

 

Here's what I learned. 

At the time I did not know that IE browsers attempt to retrieve favicon.ico from ther root of your website every time they make a page request. (How to add a favicon to your website)

Also, I did not know that this generated a 404 error in the IIS log every single time they tried to retrieve it unsuccessfully.

Also, I did not know that some web application firewalls (firewalls that constantly learn and update themselves to prevent security breaches) will actually stop responding to requests that are consistently turning up 404 as a safety measure.

Columnist Ivan Ristic comments on web security "The point is that you are not looking for a single suspicious action any more - you are using counters to look for anomalies. Other examples include looking for IP addresses with too many failed requests (too many 404 responses typically point to web application scanner activity), enforcing session inactivity timeouts, session duration timeouts, and so on."

Lastly, and the final piece of the puzzle. I did not know that:

Internet Explorer 7 (IE7) has an extremely long time out for requesting favicon.ico. ("a hex with a lot of F's" said the Microsoft Support Engineer)"

In Predictably Irrational Dr. Ariely discusses how even irrational behavior is predictable. More specifically how irrational economic behavior is predictable. He calls his study of irrational economic decisions behavior economics. Many facets of the irrational behavior in humans is covered in the book. I'll pick a few of my favorites, relativity and pricing and apply them to interests in my life, girls and coding.

Many books have been written for people on the best way of attracting the opposite sex. In his book Dr. Ariely boils this art form down to an easy notion, relativity. Humans need a direct basis of comparison for everything in their life. This means, when a person is looking for a mate they should make sure their wing person is uglier than them. Dr. Ariely conveys that every human basis's worth using comparisons, not on the function the object offers to their life, but on the function the object offers in comparison to a comparable object, in this instance another person. A great example of this is pointed out in the first chapter "The Truth About Relativity." He uses the $275 bread maker made by William-Sonoma (W.S.) to assist his case. The bread maker sales were lower than expected. The problem being consumers didn't have a basis for comparison. How did consumers know what a quality bread maker was? Worse yet, consumer were comparing W.S. bread makers against coffee machines. W.S. wants consumers to buy both products and not view one as a substitute for another. After deliberation W.S. decided not to discontinue the bread maker, but to introduce a second larger and more expensive model. Thus, giving customers a basis for comparison. As a result the less expensive bread maker flew off the shelves. Having another bread maker to compare against consumers were no longer confused if they wanted a bread maker or the coffee machine, they knew they wanted a bread maker and could easily make a decision on quality based on comparing the two products. Bread makers are not humans, is what most will think. Wrong. Humans base beauty off comparison, don't believe me, walk into a bar with a model, see who gets more attention, then try walking in with a weight watchers "point counter" put an appetizer in front of them and watch how much attention you get while your wing person forgets to breath as they devour the spin dip.

Now offering nerds an insight to the book. Let's say a programmer has written the next killer application (app). This app will change the world, but how does one price an app? In chapter ten "The Power of Price." Dr. Ariely covers this dilemma quite well. Dr. Ariely states two mechanisms shape the expectations on the price we pay for things. One is belief and the other is conditioning. An example of belief is provided with a humorous viral video which has a man following around the now famous "free hug" people carrying a sign that states "deluxe hugs." Watching the deluxe hug video from an outside perspective it's apparent there is no difference from one hug to the other, but the deluxe hug huckster makes people believe there is a big enough difference they pay him $2 for what should cost nothing. Examining the second mechanism, conditioning, Starbucks provides insight. Starbucks made people comfortable with the idea of a $4 coffee, when they were used to paying $.80. Starbucks conditioned the customer with incremental price steps into finally accepting that a $4 coffee was indeed worth $4's. Now looking at the developers app, the developer should ask themselves if there are similar apps.  If so, does the developer want the consumers to view the app as the premiere expensive app, or a cheaper competitor? Does the developer believe that people will value the app enough to pay for it? Will the developer have to condition the consumer to the cost by gradually working the consumer to accept the price the developer wants to charge?

As cliche as it sounds, once I picked up the book I couldn't set it down nor could I stop thinking of the application it has. I realized I had fallen victim to the marketing ideas portrayed in the book. Oh well, now I know.

Yes it's finally here, the yellow cab of the sky is beginning to offer wifi on their planes. On my flight home from Oakland I was informed Southwest was on a free beta period in which you could access the internet once the plane was above 10,000 feet.  First question: "Free beta," does this mean our friendly SWA will charge?  Given their cost cutting business model, I would bet on yes.  The second question: Why above 10,000 feet?

Did I use it on the flight? Sadly, no. I was coming back from a weekend of turning 30 in which sleep was, well, optional.

I look forward to seeing the free wifi on all Southwest flights in the future and hopefully the corporate Southwest gurus will let wifi be free!.