ASP.NET 3.5 For Dummies®

Chapter 19. Validation in Depth

In This Chapter

• Why user input is evil

• Checking for a range of values

• Avoiding cross-site scripting hacks

• Being a regular expression kind of person

• Escaping with your HTML

Is there anyone who likes filling in forms? Paper forms are the worst. In the passport office, you can line up for hours while desperately hoping that you've entered the right information. At the business counter, you hold your breath as a clerk checks the fields in your passport application. While she ponders too long over an answer, you fear that you're living the old game of Snakes and Ladders (also known as Chutes and Ladders). Providing an unsuitable answer is like landing on a 'Snake' square: Fate sends you sliding helplessly back to the wrong end of a growing queue.

Web forms aren't that much easier than the passport office. You dutifully and diligently fill in a dozen text boxes on a page. You click Submit, and . . . #@$%^&! . . . your answers disappear into a blank screen! Trying not to panic, you click the browser's Back button to recover your input, only to read that the page has expired. Expired? It was fresh only a second ago!

Meanwhile, on the other side of the server, Web developers don't like forms either. Users don't pay attention to what the form is asking. People enter bad data, no data, and sometimes, malicious data. Validating their responses takes a lot of effort and you'd rather leave it until the end.

The ASP.NET team provides controls that take some of the ...