I had a hell of a time tracking down a problem that was occurring on a remote web service/web server today and finally came to this. Hopefully, if this helps someone else in the future, then my hours won’t have been totally wasted.

I have a webservice that is required to return a recordset (this is an old app that I wrote a lot about in the past) and has been in production for 9 months with no problems.

Since it had been written and deployed in aspnet 1.0, I just left it alone although all of my later apps were in 1.1. The application had a windows form front end and a web service backend. I finally updated the webserver at my client site to 1.1 and it broke that application.

I tracked down the problem finally to the ADODB wrapper, finally noticing that the ADODB.dll copied to my webservice was from 2/1/02 and the one on my development machine was 4/1/03. That still didn’t do the trick (grumble)

I had originally used some ASP style method for the parameters – since I have to use ADO to deal with the recordset, not ADO.NET which basically worked like this:

Dim oprm As New ADODB.Parameter
oprm = oCMD.Parameters.Item(1) ‘sampleid
oprm.Value = SampleID
Dim oprm2 As New ADODB.Parameter
oprm2 = oCMD.Parameters.Item(2) ‘testenum
oprm2.Value = testenum

Now the application was crapping out at “oCMD.Parameters.Item(1)” telling me that the object variable was not set.

This was working perfectly fine on my development machine against my w2k3, IIS6 and SQL2000 but NO LONGER WORKING on my client’s W2000 server, IIS5 and SQL7.

Finally after a lot of testing, watching sql profiler, and general state of aggravation, I found that this worked:

One thing to consider when rendering output to the browser is to htmlencode any text that you are sending out to the browser. eg. label.text=htmlencode(mystring). It’s pretty obvious to do this with direct user input – for example a search form where you spit back “Your search for ‘dogs’ resulted in 23 articles”. But consider user input that has been stored in a database. That is STILL user input! Perhaps a user profile where “favorite color” = “<script>alert(‘you are SOL dude’)</script>”. So even though the text is not coming from a form input page, it is coming from your database, you still need to htmlencode.

HTMLEncode is not always going to be the solution, but you should use it by default and then decide not to use it if you have a reason. Here is a post by Jon Box where he has a similar conundrum.

Similarly, the Page object’s ValidateRequest (in ASP.NET 1.1) which is on by default, is not going to be helpful 100% of the time but you also need to be very thoughtful if you are going to turn it off. Here is some more info on that from Don Kiely.

Peter Blum, who has a bunch of fantastic asp.net controls on the market – said he is getting read to add some new validation controls to his already fantastic validator control package. These will be for dealing with possible cross-site scripting and SQL Injection attacks. Keep an eye on his site for when he’s got them ready.