Be Sure to Handle Errors to Continue Script Execution

I recently spoke with a developer who was upset that the redundancy he built into his Web application had failed him. As a safeguard against database failure, he had written a script which wrote new entries to a log file on the local file system as well as adding them to the database. It was a good idea… unfortunately the implementation wasn’t so good.

The fact that he was writing to the log file first gave him a false sense of security. You see, every time there was a problem with the database he’d always gone to check the log file and found the missing entries there waiting. The problem didn’t become apparent until someone accidently changed the permissions on the log file and his script threw an ‘access denied’ error which halted execution. It never even tried to write to the database and the new entries were lost completely. So what did he do wrong?

He never added any error handling to the script. If he had simply added a “Try… Catch… Finally” block around each of the operations, the script would have achieved the desired result. Even if he didn’t take the time to do anything to actually handle the errors, execution would have continued and the script would have at least tried to write the new entries to the database instead of coming to a dead stop when it ran into the permission problem.

For those of you who aren’t familiar with “Try… Catch… Finally”, here’s a short sample script which illustrates my point. This script attempts to write to a log file and send an email. I’ve wrapped both operations with a “Try… Catch… Finally” block so if either (or both) fail, as they probably will if you try and run the script as is, execution will still continue to the end of the script. For illustration I’ve included status messages which the script will display as it runs. It’ll also output the text message of any errors it encounters at the bottom of the page.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
‘ Try to write to a logfile and send an email, writing status messages as we go…
litPageProgress.Text = “

Page_Load sub started execution at: ” & _
Now().ToString & “

” & vbCrLf

litPageProgress.Text = litPageProgress.Text & “

Attempt to write to log file… ”
Try
File.AppendAllText(Server.MapPath(“logfile.log”), Now())
litPageProgress.Text = litPageProgress.Text & “Succeeded!”
Catch exLogFile As Exception
litErrors.Text = litErrors.Text & exLogFile.Message & “
”
litPageProgress.Text = litPageProgress.Text & “Failed!”
Finally
litPageProgress.Text = litPageProgress.Text & “

” & vbCrLf
End Try

litPageProgress.Text = litPageProgress.Text & “

Attempt to send email… ”
Try
Dim mySmtpClient As New SmtpClient(“localhost”)
mySmtpClient.Send(“FROM_ADDRESS”, “TO_ADDRESS”, “Message Subject”, “Message Body”)

litPageProgress.Text = litPageProgress.Text & “Succeeded!”
Catch exLogFile As Exception
litErrors.Text = litErrors.Text & exLogFile.Message & “
”
litPageProgress.Text = litPageProgress.Text & “Failed!”
Finally
litPageProgress.Text = litPageProgress.Text & “

” & vbCrLf
End Try

‘ Note that this line will still run even if errors occur above.
litPageProgress.Text = litPageProgress.Text & _
“

Page_Load sub ended execution at: ” & _
Now().ToString & “

” & vbCrLf
End Sub

Try… Catch… Finally Error Handling Example

Errors Encountered:

web application – DHTML or Silverlight?

I want to develop a web application and I am not sure whether I should do it in DHTML or Silverlight.

I could use the rich UI capabilities of Silverlight, but on the other hand
Silverlight is heavy on the client and not many users installed it.

Are there any solutions or suggestions ..?

 

So why not Flash? Richer than DHTML and it’s pretty much universally installed by users.

Why stick with MS tech-not-logies?

Help Stop Cross-Site Scripting Attacks with HttpOnly Cookies

Did you know that there’s a simple little change you can make in the way you handle cookies that can help prevent your users from falling victim to a cross-site scripting attack? Implementing HttpOnly cookies is quick, easy, and goes a long way towards making your application safer for everyone.

HttpOnly cookies behave exactly like regular cookies with one important difference: they cannot be accessed by client-side script running in the user’s browser. This doesn’t seem like a big difference until you realize that many cross-site scripting exploits depend on this very capability.

As long as you’re running .NET 2.0 or higher, you can enable HttpOnly cookies in a couple different ways. The easiest is to simply edit your application’s Web.config file. Setting the value of the httpOnlyCookies attribute of the httpCookies element to true will convert all the cookies your application sends to the HttpOnly flavor.

<system.web>
    <httpCookies httpOnlyCookies="true" />
</system.web>

You can also do the same thing for individual cookies that you set via code. It couldn’t be much easier as you can see in the following listing:

    Dim myCookie As HttpCookie
    myCookie = New HttpCookie("LastVisit", DateTime.Now.ToString())
    myCookie.HttpOnly = True
    Response.AppendCookie(myCookie)

Now for the bad news: HttpOnly cookies only work in relatively new browsers. Older browsers will either treat them as regular cookies or ignore them altogether. If you happen to have a user base which is particularly behind the times, you’ll need to do some testing to see how your application behaves in their browser(s) of choice.

For more information, you may find the following links useful:

• Mitigating Cross-Site Scripting With HTTP-Only Cookies
• ASP.NET Settings Schema: httpCookies Element
• .NET Framework Class Library: HttpCookie.HttpOnly Property

Update: HttpOnly Cookies in ASP.NET 1.x and Classic ASP

I’ve gotten a number of email from users anxious to use HttpOnly cookies in their legacy Web projects. Rest assured, you can get the same HttpOnly functionality regardless of your server side tool of choice… it’s just takes a little more work.

For those of you using ASP.NET 1.x, try this code:

    Dim myCookie As HttpCookie
    myCookie = New HttpCookie("LastVisit", DateTime.Now.ToString())
    myCookie.Path += "; HttpOnly"
    Response.AppendCookie(myCookie)

It’s a little bit of a hack, but it should work in most cases. The only situation I can think of that might cause a problem is if your cookies are flagged as secure.

In classic ASP it’s a little more difficult. You can’t really use the Cookie object to accomplish the task, so you’ll need to resort to brute force and use the Response.AddHeader method to set the cookie.

    Response.AddHeader "Set-Cookie", "CookieName=CookieValue; path=/; HttpOnly"

As you can see, HttpOnly cookies aren’t just for developers lucky enough to be using the latest version of ASP.NET. With a few tweaks you can use you can use them with whichever server-side technology you prefer.

Basic authentication vs. NT Challenge and Response

When you password protect a web page using Internet Service Manager, you have the option of choosing either Basic authentication or NT Challenge and Response (aka: Integrated Windows authentication). The difference in the two methods is in the way the username and passwords are transmitted over the Internet. NT Challenge and Response encrypts the password so malicious snoopers can not intercept and use the information. Basic authentication sends the password as plain text. While it would be great to use NT Challenge and Response for all secured web pages, the only web browsers that currently support this protocol are Internet Explorer 3 and higher. If you might have users with other web browsers, your only choice is Basic authentication.

If you would like to have a secure website take advantage of using encrypted usernames and passwords but still want to be compatible with Netscape browsers, you can use Basic authentication over SSL. Using Secure Sockets will encrypt the user name and password but at the same time will still let Netscape browsers use your site, the best of both worlds

Close and free up object references

While we’re on the topic of good coding techniques, I thought I would remind everyone to close and free up object references once they are done using them.

I tend to type in the commands to kill the object right after I create the object, and then start coding between them.

<%
Dim objConn, objRS
Set objConn = Server.CreateObject(“ADODB.Connection”)
objConn.ConnectionString = …
objConn.Open

Set objRS = objConn.Execute(“…”)

objRS.Close
Set objRS = Nothing

objConn.Close
Set objConn = Nothing
%>