.Net Dojo: Exception Handler

While running one or more ASP.NET websites, it is valuable to have a system where errors encountered by your users are automatically reported so that you can fix them. It is bad practice to let the user’s see the error and it is horribly evil to force them to report the errors themselves. The answer: an automatic exception handler. I developed this handler for use in websites so that any error encountered would be e-mail to a list of developers as well as recorded to the log if desired.

I also give the option of filtering out 404 (Page not found) and 403 (access denied) errors in case you only care about hard exceptions. It the past, I did see one application where we used 404 handling because the structure of the site changed. We implemented an automatic redirection for users who had bookmarks, and we caught 404 errors to find gaps in our redirector.

.Net Dojo: Data Validation

Validating data is a very important part of any application that takes user input. Without validation, users can enter whatever they feel like. This is especially bad when needing specific data, like an e-mail address.

To make things easy for myself, I have all my common validation methods in one library. Validating user input is done using regular expressions. While I do my validation on the backend, it is a common practice to use validators do do much of your validation on the client. This saves the user from having to do a postback to the server only to get an error back. I agree that this is a good practice, but for every javascript validation I do, I also validate it on the server. The reason behind this is that a user can download your html to their computer, strip out the validation, and post to your server. This was something I tested when working on websites for a certain polling and market research company. Because of this flaw, we developed a standard practice to only use required field validators for client side validation and test all other validation on the backend.

.Net Dojo: Forgot Your Password Workflow

As an experienced web developer, I have seen all kinds of crazy login workflows. The security question workflow, however, is the absolute dumbest workflow ever. Not only are most questions geared at public domain information, but how many people are actually going to remember what they typed in for their answer? Also, depending on how good (or bad) the programmers are, if the answer is case senstive, or miss-spelled, you are hosed. I can’t stand sites who use this workflow when there are much better, and more secure ways to allow users to regain control of their account. To learn more about why this type of authentication is bad, read Wish it was Two-Factor by Alex Papadimoulis. He discusses how the secret question does not fullfill two factor authentication by any means.

.Net Dojo: Getting Around ActiveX Activation

Have you ever gone to a website where you have to click to activate a flash control?  This is only an issue if your users use IE.  A blaring example of this is to open any wordpress page that has Youtube video on it.  You have to click it before you can actually click it to start it playing.  Microsoft was forced to enable this on their browsers, but there is a very simple solution to the problem that only a few website developers seem to implement.

According to the W3C, IE was used by 57% of the people browsing the internet.  If you are using flash on your site and you are not using a workaround for activation, you are annoying over 1/2 your user base.  Lucky for you, I have compiled the solution into a simple ASP.NET 2.0 control that you can use.  Don’t like ASP.NET?  You can take the principals of the workaround and apply them to any language.

The basis for the workaround is that any flash tags written via javascript are immune to the ActiveX activation.  The problem that I discovered while building this control is that all browsers behave differently when it comes to javascript.  My first version of the control used <noscript>…</noscript> tags to show the control normally if the user has javascript disabled.  The problem we found is that Safari does not support noscript tags.  On Safari on a mac, no flash would appear.  So, I reworked the control to detect the browser version.  If it is any version of IE, it uses javascript to write the flash and <noscript>…</noscript> as a backup.  For all other browsers, the ActiveX activation is not a problem, so I just write the flash out normally, thus eliminating the pesky javascript issues.

.Net Dojo: Cookies with ASP.NET 2.0

Recently I was testing the cookie class for my library of utilities called Olympus. This library consist of commonly used things like cookies, a database provider, memory caching, error reporting, and other tools. I stumbled across a big change in the way cookies are handled in .NET 1.1 and .NET 2.0. Here’s how I made cookies work.