Error ... error ... whence cometh thou?

I'm working on a page that will allow our users to view a table in a database in ASP.Net. To do this I am writing a UserControl where I am connecting to the database through a SqlDataSource, and I bind a GridView on the UserControl to this datasource. If you are unfamiliar with databinding this simply means that I hook the presenting controller (the GridView) up to an object that can provide it with data. This automagically populates the presenter with the data from the source. But, as with all automagical things can, and do, go horribly wrong.

Small digression: I'm from the Java plains, but I've recently set up shop in the .Net woods where I mostly hang around in the soppy marshes of ASP, the glossy banks of MSSQL-RS and more recently the crags of ADO. Being quite new in these parts I get to do a lot of really stupid things, and I'm building an appreciation of each land's pros and cons. One of my gripes with the marshes of ASP is the incessant focus on doing things declaratively as the first-choice. Sure, it's great if what you want is static, but I don't want static content!

Why this rant? Declarativity just bit me in the rump, like a particularly nasty ass.

So, I was binding my GridView to the SQLDataSource declaratively, like a good ASP-ape. Everything was working as expected until I started testing the page with non-standard inputs. The datasource is setup with the data it needs to connect to the database, and an initial select statement to get at the data you want. If any of this is incorrect the entire page explodes in a messy way. Red goo all over the walls.

My test-case was simply setting up the datasource with an incorrect login. This caused an SQL-exception when the SQLDataSource tried to perform the initial Select (as one would expect). Now, .Net does not have checked exceptions (expect a post on this later), so being from the Java-land I am always a bit surprised and worried to see exceptions being thrown willy-nilly run-time.

Well, this exception I should be able to deal with. It is a real problem, but the application should be able to handle such problems gracefully. I just had to find some place to catch this exception, and handle it.

There are several places you can handle an error in ASP.Net:

• global.asax (where you can handle application-level errors), overriding one of the following methods
  
• Gobal_Error
• Application_Error
• Page_Error (where you can handle errors on a page-level)

In addition to this you can define a page to send the user to in case of an error, so the plebs don't have to see the ugly innards of your app. All of these solutions are good, but not for my use-case where I actually wanted to handle the exception, should it occur. These solutions let you do things like log and redirect on errors, but offer little in the way of actually handling the problem.

Yes, on a page I could have used the Page_Error, the problem is that I am building a UserControl, which is part of a page, but not the page itself. And, a UserControl has no onError event to catch, and on Error method to override. In effect the UserControl blew up, killing all bystanding controls and page-elements.

Digging in to where the error originated I saw that it was spawned when the controls on the page where coming to life, in the preRender -stage of the lifecycle. This tells me that I must place some code to handle this before that stage of the lifecycle to avoid this error. In the purely declarative mannar I would declare a handler for some SqlDataSource error event, but that component does not have one. So I am relegated to provoking the error myself, and handling it correctly.

This is not really all that hard, once you've gotten to this level (the realisation that I had to do it this way took much longer than the coding of the fix). What you're forced to do is to not bind the GridView to the SQLDataSource declaratively. Read that again. To handle the error you're forced to step out of the declarative world and do the binding yourself. Now, this isn't hard, but it suddenly seems as if the declarative way of doing things is second-rate and sunshine-days-only. I can live with that, but what I really don't like is how every example focuses on declarative implementation, when it's the less powerful and (to me) less natural way of doing things. Sigh.

Oh, well, on to the fix. Just remove the DataSourceID="someDataSource" element from your GridView decalaration, and add something like this to you Page.Load handler:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
	theGridView.DataSource = someDataSource
	Try
		GridView1.DataBind()
		btnSave.Visible = True
		lblError.Visible = False
	Catch exc As SqlException
		lblError.Visible = True
		btnSave.Visible = False
		lblError.Text = "Could not load table: " & exc.Message
	End Try
End Sub

This will let the UserControl come up, even if the datasource experienced an error. Much better, but I'm left feeling it's dumb that I have to do it this way.



Technorati Tags: asp, usercontrol, exceptions, declarative, gridview, datasource, error

Let's Talk About It...

"Let's talk about it..." that's the name of the latest version of Jade, that was released yesterday! That's right, a new version of everyone's favourite FIPA-compliant Java-based multi-agent framework has a new release. And this is just, what, a month or two since the first book about the framework was released (Developing Multi-Agent Systems with JADE).



Exciting times!



So, what's new in this release? Any breaking changes? Let's have a look at the press-release (I haven't had time to try it out yet. I'll do that at my first opportunity and post my impressions).

• A whole new communication mechanism: Publish/Subscribe!
• A whole new mechanism where agents can simply register a topic they are interested in, and every message that is broadcast with that topic will be sent to them. This sounds like a good idea to me, uncoupling the broadcaster and subscribers. It is only applicable to general broadcasts, though, and I wonder how they implement "closed" lists.
  
  
• Sounds like they are implemented by making a proxy-AID representing the topic, to ensure compatibility. I wonder if this is a good thing, is breaking the agent-AID binding really something you want to do?
  
  
• A "completely restructured version of the Web Service Integration Gateway"
• Web app (can be deployed to app servers, like Apache Tomcat)!
• Web-services are derived from the actions in the ontologies registered to the Directory Facilitator.
• WSDL document generated for each agent service exposed (how did they do it before?)
• I haven't used the WSID earlier, so I can't really add any thoughts to this, check out the guide here.
  
  
• Improved detection of main container using UDP Multicast packets
  
  
• Excellent, this makes it easier to set up multi-platform environments!
• A reflector, finally allowing us to use the Java Collections Framework when working with ontologies
• Excellent stuff, now just port the entire thing to Java 1.5 to give us generics!
  
  

All in all some exciting stuff! Let's hope this one doesn't break anything, eh? I've not touched it yet, and so far on the mailing-lists there's one user who's had problems with the multicasting on his machine, but it looks like a he found a workaround (detect-main option set to false).



Let the bugsearch ensue :-)

If you met God on your commute

Here's a nice little story...



Talking to God...

Which tables do I have available?

Sometimes when you're connecting to a database you'd like to know what tables are available. I'm no DBA, so it took me a while to find out how to do that.



In this case I've just gotten the connection stuff from the user, and I run this code when the user presses a "Connect" button to connect to the database the user has specified and populate a drop-down box with the user-tables in that database. The real meat here is the selectTables string in there, which gets the user-tables from the sysobjects table. Once I get this I bind the drop-down box (ddTableSelect) to these to show all the tables.

Protected Sub btnConnect_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnConnect.Click

	Dim builder As New System.Data.SqlClient.SqlConnectionStringBuilder



	builder.DataSource = txtDatasource.Text

	builder.InitialCatalog = txtInitialCatalog.Text

	builder.UserID = txtUserID.Text

	builder.Password = txtPassword.Text



	Dim selectTables As String = "SELECT sysobjects.name, sysobjects.id " _

	  & "FROM sysobjects " _

	  & "WHERE sysobjects.type = 'U'"



	Dim source As SqlDataSource = New SqlDataSource(builder.ConnectionString, selectTables)



	ddTableSelect.DataSource = source

	ddTableSelect.DataTextField = "name"

	Try

		ddTableSelect.DataBind()

		connectedState()

	Catch ex As Exception

		lblError.Text = "Could not connect: " & ex.Message

		errorState()

	End Try

End Sub

To be perfectly clear, as VB can be a real pain on the eyes (and SQL is soooo much better, right!?) this is the SQL that gets the tables:

SELECT sysobjects.name, sysobjects.id 

    FROM sysobjects

    WHERE sysobjects.type = 'U'

Yes, I know, catching all exceptions in the end there is bad, but this is me feeling my way, ok?

There's a bug in the compiler

Or so they say.



I was making a new page-control today for my app. Using VS this can be done by adding a new controller to the page through menus, or you can just do what I do. I copy an old one, and paste it in, changing the Class names and removing most of the code. This bypasses all the tedious setup, and all the bits that have to be there for the framework I'm working on are already there. Goodness.



Happily I build, expecting no errors, but I get a nasty message. "Custom_Report is ambiguous in the namespace 'ASP'". Not good. Custom_Report was the name of the control I copied, so I go back and double-check that I changed the class-name. Yes, yes I did.



That's strange. Well, a quick search online told me that this might be a result of a known bug in the compiler. The fix was easy, you have to compile your app in non-batch -mode. How do you do this, I hear you asking. Simple: enter the compilation section of your web.config, and set batch="false", as so:

<compilation debug="true" batch="false">

...

</compilation>

This has been your small-problem, small-fix.

Don't Store That Password (Client)

Passwords, passwords, passwords. They're all around us, and they're a pain to remember. How do we cope? There are hundreds, possibly thousands of places where I use passwords. I have trouble remembering one password, those numbers would be ludicrous to even try. How do you cope? You make up a strategy, or you get tooled up.

Traditionally we say there’s three main ways of asserting an identity. Something you are, something you know and something you have. Identification consists of proving one or more of these to a given level of confidence. A low level of security could include simply asking someone who they are. If you want a higher degree of certainty you could ask for more than one element of identification.

The most common way of doing this is by asking for two of the three elements above, who you are and something you know (username and password). When you want higher degrees of security you can add the third element (something you have, like a key) or you can go deeper into each of the elements. Going deeper into who you are is the direction of biometrics. Delving into something you know would include asking questions you’d know but none others would, and not asking the same question every time. Gaining security on the “have” element would include making very sure the item really does belong to the person who’s trying to identify himself and making equally sure that thing really is that thing. One-time pads and secure transfers are key here.

This all seems nice, and it is. You know what else it is? It’s a hassle. So far most services contend themselves with a two-pronged check (username/password), so you need to give that to get access. This is fine for one or two services, but we’re all consumers of hundreds or thousands of services. To add to this you really should keep different passwords for each service, to ensure your security. If you use the same password for every service and one of your providers are hacked (or *gasp* are bad-guys and sell or use your password) all your information is compromised. So we make up passwords.

To protect ourselves from brute-force hacks we make up complicated passwords with at least 8 characters and combinations of upper-case (A-Z), lower-case (a-z) and numbers (0-9). The really paranoid among us throw in a couple of non-obvious ones too (β, æ, °, etc). And you have to remember all of this. It’s all a bit hairy.

We need some way to solve this problem. Luckily there are solutions. What you need is a strategy to keep track of your passwords. There are three obvious strategies (well, more, but this isn’t a book, it’s just a post).

1. Make up a (hopefully strong) password and stick with it for every service.
This is a bad idea in general, but it’ll do if you don’t care about the information you put into the services. This means your information is wide-open to any hacker after they’ve somehow gotten hold of your password.

2. Make up a few (hopefully strong) passwords and use different ones for different services.
This is what most people do. You have one password for your work-things, one for throwaway-accounts you don’t care about, one for your personal stuff, etc. Although this is a step up from number 1 it’s still not what I’d call security. Two things to think of here are:
a. Are you sure your other passwords aren’t stored somewhere you can get to from one of the identities? If you store a list of passwords on one account any hacker who’s gotten into that has access to all your other information.
b. Are you sure you won’t try all possibilities if you can’t gain access on one service? If a hacker has control over some service you use and changes the password he could probably get a few good passwords out of you when you try all the possibilities. I know I would try every option before giving up.

3. Make up some personal rule for your passwords. This is a good way of coping with the problem as long as you keep this rule secret. Say your rule is “The first three letters are from the beginning of my pet’s name, after that every even character spells out my post-code backwards, every odd character spells out the name of the service. Every other letter is upper-case.” This would make my youtube –account’s password “eRo1E6b1U5tUoY”. Kind of cool, and quite hard to break as long as you don’t tell anyone what your rule is.

So we have some inkling on how we could do this, but it’s still a hassle (well, number one isn’t really). So we’d like some tools to help us. Number one doesn’t really need a tool, perhaps a paper-note if you’re a goldfish. Number two could also be covered by a piece of paper, but with tools we can improve on this. This is where personal password-keepers live. You make up a set of passwords and keep them somewhere safe (like in a database). Safe as in – won’t disappear, and hopefully safe as in won’t get to others. However if your password-database is compromised you’ll effectively have shot your guard in the rear. You’re wide open. And, let’s be fair here, you won’t use all those random passwords anyway. It’ll be too much of a pain and you’ll go back to your old scheme of one or a few passwords.

The third option though is still fascinating. If it’s an easy rule you can use quickly you won’t need a tool. However, with a tool you can make a really complex rule that nobody would ever guess! The world would be your oyster! A one-way-function would be ideal for just this purpose! Hashing-functions are popular for this purpose.

Hashing for dummies:
For our purposes hashing-functions are a black box you put some number into, and some other number comes out. Every time you put the same number in the result is the same, and crucially, there’s no easy way to go the other way! If someone had your result (the hash) and the hashing-function (the black box) they still have no easier way of finding the number you put into the black-box than trying every possible number. (This is all slightly false, but it’ll do for now).

So, what you do is get yourself a hash-function and enter the name of the service into that function. This way the hasher can make you a service-password that’s unique for that service, has no apparent connection to you and will be generated every time you put the name of the service into the function. Oh, you say, but everybody else using the same hashing-function would get the same password! And, you’re right, I’m proud of you. You’ve obviously been paying attention. What you do is you “salt” the hash. Salting the hash means you don’t just enter the name of the service but also enter something else. This “something else” would be your master-password.

Let’s assume you’re able to remember one password and what you called the service – this will always give you the password for the service. As long as nobody else has the same password and name for the service they’d not have the same service-password. Even if they did any hacker with control of the service wouldn’t know what the password-name-combination was, he’d only see the service-password.

This is great, the problem is solved. Well, the problem was already solved with strategy 3 back up there, but people are too lazy to think of strategies. Now, how can lazy people get to use this marvelous technology? We have to give people hash-functions! Luckily these are available. Popular ones are MD4, MD5 and SHA-1 (I know, they’re broken but they’ll do for our purposes). You can try them out at http://pajhome.org.uk/crypt/md5/

If you use Firefox (and I think you should) you can install a bookmarklet called SuperGenPass This makes the entire operation automated, and it fills in the generated password based on the name of the server you’re trying to connect to and your master-password. It’s so easy you’d never think it was safe, but it really is!

This has been a short essay about how the client can get some security from hacked or malicious services. As a developer I see the problem from the other side as well. I’ll delve into that next…

Been Sick

I've been out sick for a while, sorry. That's why there's been no new posts for a few days. Just thought I'd tell all my millions of readers.

The good news is that I'm well again, and I've got a few posts coming out soon.

For now, take a look at the interesting things I've put on the sidebar. Not my content, but all of that is stuff I found interesting and worth a little time.