Why Blog?

Having recently asked myself this question I was very keen to have a read of this post over at Newly Corporate. I think they've made some excellent points - but I would expand on something they've touched on with point 2.

When they say it's a good way to practice project management I would say it's more than just a way to practice. I would say that a blog is a way to teach. Not in a condescending sense, but as a sharing exercise. Something I've picked up recently is that there are three key tenets to learning - discover, master, influence. Blogging is a significant part of mastering, and influencing in my opinion.

The reason being that in my opinion you don't truly know something until you can successfully teach it to somebody else. Once you have that ability you have mastered the subject. You can then influence peoples thinking by guiding them in their learning while teaching. This not only reinforces your subject matter knowledge but also drives your social interaction skills, which they also mention.

So why do you blog?

ASP.Net AJAX Auto Complete Control Extension

Today while working on adding tagging to items, I came across an issue with the auto complete control extender available in the ASP.Net AJAX Control library.

The problem is that you can't host the extender in a custom user control (ascx file) and make it call back to a Page Method to retrieve the auto complete list. The reason for this is that the PageMethod() function in the javascript that is used to drive this functionality only hooks into the page itself, not the hosted control.

I've got a quick and dirty workaround for this, which works for me in the short term but I'm going to work on refining. It goes a little something like this...

Set up your extender in your user control...


Configure your script manager to allow calls to page methods...


Add the following method to your page. It's important to make sure the signature matches exactly!


Then simply add the code you need to retrieve your item list to the method body. The hook will now catch the GetCompletionList method as it should and the extender will populate as normal.

Where to next? I'm currently investigating the possibility of using the StackFrame class to branch to different methods based on the caller to this method. There is potential then to have multiple auto complete extenders on the same page across various controls.

If you've done something similar - or have a better way to do this, leave a comment and let me know. I'm sure there's a better way out there... I just haven't got there yet :)

MaxLengthTextBox - AJAX Control Extender

If you're looking for an easy way to apply a max length to an ASP.Net multiline text field, I've written a control extender that is compatable with IE, and Firefox. It uses .Net 3.5, and you'll need to go here and grab the toolkit. Once you've done that, head here to grab the extender. Put a reference to the toolkit in your project, then reference the assembly I've provided.


Now all you should need to do is add the extender as per any normal extender. Set a max length for your text box, and you should be good to go!

If you've got any comments, suggestions, improvements or even ideas for other controls leave a message on the codeplex page, or here on the blog.

ASP.Net AJAX Extenders

As mentioned in my previous post it's been quite a while since I last had the fortune to work on a web application. Today I discovered another gotcha for young players in the web world when trying to set the MaxLength property of a TextBox control. Normally this works fine, but if you combine this with settinig the style to MultiLine the world changes.

What's going on here is that the TextBox control is rendered in 2 ways. Normally it's rendered as an input control, which allows the max length property to work as intended. However, in multiline mode it renders as a TextArea control, which doesn't implement the MaxLength property! No good for those of us attempting to limit our user input lengths...

So how to fix it? After spending some time playing with validation controls combined with update panels I decided it just wasn't going to happen unless I started writing some script. Now I normally shudder at the possibility of working with script, but I really have to say that it's been quite pleasent this time around.

I downloaded the ASP.Net AJAX control toolkit and took a look around to see how these extenders are put together. Basically they consist of a behaviour (client script), an extender (server side code), and a designer (to allow for use in the IDE). It seems that with the toolkit, most of the hard work wiring things together is done for you. All you really need to do is define any public properties you'd like to implement in your server side code, wire them up using the provided Get and Set methods from the toolkit then get to coding your behaviour in the script files.

For my particular problem there was already a number of solutions out there, on CodeProject and also on various blogs. I've ended up with a nice mesh of a few solutions that involves filtering the key down event to check the user input once the control reaches the max length then allows or denies the key press events to continue firing. It's not quite in the wild yet, but I'm hoping it will survive the rigours of beta use and prove a worthy addition to our internal toolset.

I'm also putting together an article on how I went about writing the extender for those interested. So if that's you - watch this space :)

References:
Multiline TextBox with MaxLength Validation
ASP.Net AJAX Control Toolkit
Keyboard restriction textbox with options and ñ
Detecting keystrokes

Http Request Validation

Last week while working on what amounts to my first website in a very long time, I stumbled across something I hadn't seen before. I was working on a bug that allowed the input of script tags into free text fields. This was causing the browser to pop up various HTTP 500 errors. The answer as to why, lay in the stack trace.

What the good old trace told me was that my page was attempting to validate the HTTP request before it was sent to the server. It turned out the page was throwing a HTTPValidationException which due to the error model used was being swallowed by the page and subsequently presented as the more general HTTP 500 error. Below is the screen I would have got, had I not swallowed the error...



Now I knew what I was dealing with I went to take a look deeper into what was happening here. Down my stack trace there was a pointer to the Page.ProcessRequest method with the HTTPContext being passed in. What was going on was that when this method was called it was validating the request to ensure there was no potentially nasty hacker bits in there.

So - ASP.Net was being a good mother and making sure I couldn't inadvertently hurt myself by allowing people to insert HTML tags into my text fields. Wow I thought, that's pretty neat! As neat as it was though, I had to fix the error. So where to from here?

The next step was once again google. I came across a number of posts on the ASP.Net request validation process - I've linked a couple at the bottom that I think are worth a read, and in summary there is 2 ways you can handle this type of error.

1. Disable request validation on either a page by page, or application basis.
2. Handle the error gracefully in the Application_Error method of your global.asax file

Needless to say, they both have their merits. For my particular scenario, where I wanted to allow the widest possible range of input I chose to go with option 1. The problem with option 2 is that even if you do handle the error, the best you can do is hand the user back to their previous page, with or without their previously entered data and a warning not to be so naughty next time.

Even though I chose to disable the request validation in some of my pages, I still needed to cater for the possibility of script tags being inserted into text fields. Otherwise, I was vulnerable to various forms of scripting attacks. So what to do? The answer is really quite simple, use the HTTPUtility class member HtmlEncode (string Server.HtmlEncode(string)) to render the input back into it's HTML equivalent. This converts all angled brackets into their &lt and &gt equivalents and renders any attempted script pretty much useless.

There is one last gotcha to be aware of... In some controls you will need to decode the HTML back into it's character form. This can be done once again with the HttpUtility class member HtmlDecode (string Server.HtmlDecode(string)).

There are other approaches to solving this problem, and you should consider doing more than just the HTML conversion of input if you intend to turn off request validation at an application level. I suggest that you head over to the MSDN guide on preventing script injection attacks at least to take a look at some other approaches. That or let ASP.Net do your heavy lifting and validate all your requests for you!

Refs:

1. Security Practices: ASP.NET 2.0 Security Practices at a Glance
2. How To: Protect From Injection Attacks in ASP.NET
3. ASP.NET Internals – IIS and the Process Model
4. Scott Hanselman's ComputerZen.com

Now with Vista!

I've gone and done it now. After a quick trip to local PC fair yesterday to get some more RAM and another HDD I've installed Vista on it's own partition. I haven't gotten rid of XP yet, as I've got a fair bit of stuff to move over onto either my storage partition or to install with Vista but I'll get there.

Now to spend the morning re-installing VSTS, Office and all the 3rd party apps! :)