I've seen some blog postings out there recently on what to do if your contact form fails for some reason. Some have suggested including your email address using JavaScript, which I do not recommend. Some people even suggest substituting "@" with "at"; if I was writing a screenscraper, this is the first thing I'd check for, after "dotcom"! If you're going to try and include your email address, then why bother with a contact form in the first place?

I've been using my own standard contact form for some time now. It displays either a success or error message upon submission. If there is an error, then it generates an email back to me. In fact, I like to have an email generated whenever there is an application error in a client's website, and I include this as part of routine error handling in my projects. This works for small projects where it is unlikely to over-burden the mail server. The strategy pattern helps me to factor out this kind of repetitive functionality; see an earlier post about this. At the end of this post, you can find a link to download a simple contact form.

A lot of people have problems testing email with ASP.NET. The simple answer is to use a drop folder on your local machine when developing. Just create a folder called "maildrop" on your c:/ drive and use the following in your Web.config file:

When you are ready to deploy your application, simply comment out the above entry in the config file and use the usual syntax below. Keep the drop directory section commented out in your config file as you might need it later for testing or further development:

For the CSS purists out there, this is created using tables because we are more interested in the functionality here. If you want a CSS contact form layout, just holler in the comments :-)

Depending on the importance of the project you are working on, you may want to log the errors to a database. This is simple to do so I'm not going to delve into it here. Note, that there is nothing to prevent you from grabbing some fine-grain error details and storing them in your errors table also. Anything that helps you identify problems at a later date is a good candidate for a table field.

That just leaves network errors. I haven't had a chance to play with this yet, but it would be nice to know in advance if the mail server was down and I'm wondering if we could somehow tap into the SMTP return status codes before sending the mail? If anyone has any suggestions along these lines, please share them here?

I'm no security expert, and as such, I think I'm a member of an ever-growing group of Web developers who fly by the seat of their pants when it comes to the security of their Web forms. As an ASP.NET developer I have had a tendency to presume that the framework is going to insulate me from most of the "nuts and bolts stuff". Of course this is not the kind of beneficial abstraction that frameworks were meant to provide us with. It is up to each of us to take responsibility for the code we create. Testing, even when it is carried out, shouldn't stop as soon as we find out that our code "is working". There needs to be some baseline better practise for creating everyday Web forms other than relying on ValidateRequest being set to true.

Recently I published a post entitled 500,000 SQL Injection Attacks. The half a million attacks actually occurred in a single week. This is mind boggling. A lot of the attacks targeted older ASP sites and I was surprised at how much of this old code was still out there. What surprised me most was how many idiots were out there calling themselves developers, not to mention the bottom-line execs who hired them in the first place. That 500,000 sites were attacked in a single week should be telling us something. We need more qualified programmers in the industry and we need the education system to introduce students to the World of IT that they are going to be living in.

Most security holes are created by developers with little understanding of security issues. These security holes are then exploited by hackers who understand these security issues only too well. It's a lethal recipe. Developers need to understand what it is they have to protect against and how to go about doing it. The tools and guidance for creating safer Web forms are available to us right now if we know where to look.

From a security point of view, our Web forms are naked and 100% vulnerable. We need to look at all the ways data is passed to them and test as appropriate:

A best practise would consist of the use of this library in conjunction with proper data validation (validators) and filtering (regular expressions). If you have existing code which you know is vulnerable you can still use tools to inspect your code and then you can implement the necessary protection measures where needed.

On the MSDN Code Gallery, there is a complete ASP.NET 2.0 Reference Security Implementation which you can download and explore. It was created in VS 2005 and includes an installer. This is a very helpful resource to answer any questions you may have. Note: you must have VS 2005 installed for this to work.

I've saved the best news for last :-) The Microsoft CIGS (Connected Information Security Group) are working on the new Security Runtime Engine. It is a HTTP module which will provide protection against the most common Web application security vulnerabilities, including Cross Site Scripting. The CIGS group are currently testing it and the beta should be available shortly.

Here's a code sample that might come in handy. This is a CheckBoxList for a fictitious Real Estate broker who wishes to maintain a list of features for each property listing entered in the system. Typically, you would create a form to add a listing and another to edit an existing listing. Loading the selected values for a CheckBoxList from the database often causes confusion and this snippet uses a Non-Typed-DataSet and a stored procedure.

You may notice that there is also a custom validator used, to ensure that at least one selection has been made in the CheckBoxList. It would be nice to add a JavaScript version of this on the client also. The following snippet is part of the page load method.

Here's the code to grab the selected values from the in-memory DataSet...

This is the call to the stored procedure from the DALC (Data Access Layer Class); the business layer method is simply a pass-through call.

Next up is a pretty basic stored procedure which simply grabs the fields containing the text for the ChekBoxList items and the corresponding boolean value, indicating whether or not they were originally selected.