A thought on not living down (or up to) stereotypes

You can say what you like about the stereotypical programmer, but suspicion of all things new is not among the standard character flaws.  Like our idols Mister Spock and Sherlock Holmes, we can dispassionately dispense with the human bias for the comfortably familiar.

And yet.

I had to add the login feature to a web application today.  There's nothing particularly exciting about that.  Until you factor in the adrenaline-kick from sheer paranoia.  Login pages, after all, are the gateway into the castle that is someone else's data.  As a programmer, you want to do your due diligence and make sure that not only is the door itself is strong, but also that the portcullis is down, the drawbridge is up, and the moat is fully stocked with hungry crocodiles.

One of the recommended ways to go about this is to integrate something called a "stored procedure" into your web code.  If you're not a code or database geek, don't freak out:  I promise not to be too nerdy.  What you basically need to know is that this code actually resides in the database itself.  Mainly that's to take advantage of the database's own...shall we say..."immunities" to potential troublemakers.

So I started going through the usual motions of cranking out typical login code.  Then it occurred to me to check in with the database's documentation to see whether they'd upgraded the functionality which encrypts text so that passwords are rendered unintelligible to humans.  As luck would have it, a new and improved encryption function was waiting.  (Which is good, because the old standard had been compromised awhile back.)  The new function was slightly different, so I tweaked my in-progress code to deal with that and finished up the stored procedure.

When I called the procedure with my login name and password, however, the database had never heard of me.  Plus there was a semi-useful warning about data being truncated (which basically means some of it's being chopped to fit a smaller expected length). 

Weird... 

A sanity-check of the documentation and some extra poking-n-prodding says that I'm using the new function correctly.  I also have enough space for the encrypted password.  Maybe I didn't correctly encrypt the password when it was added to the database.  Whatever--let's do that again, just to make sure. 

Still no joy.  Huh.

So I copied just the relevant code-snippet into a fresh query window and executed it independent of the surrounding code.  The good news is that the snippet finds a match for my login/password; the bad news is that it won't do it inside the larger procedure.  Oh, and that warning about truncated data is still there.  Wat?

As it turns out, the problem all along was with my login name.  See, I'd set up the procedure to assume that login names wouldn't be any longer than 25 characters.  But then I used a (longish) email address to log in.  Result?  The chopped-off email address didn't match what was in the database and thus wasn't recognised. The password, on the other hand, was perfectly kosher.

But because this was my first outing with the new-and-improved encryption, I reflexively targeted it as the cause of my woes.   I have to chalk up the afternoon as a net "win," because I won't forget what I learned about the encryption feature while debugging its non-existent problems.  Though it looks like I will be still aspiring to Spockian/Sherlockian dispassion when problem-solving for some time longer.