OpenID

OpenID has been in the news recently and I thought I’d cover it real quick.

The buzz-phrases are “Identity Management” and “Controlling your online identity”. But what is it really?

Essentially it’s a protocol that allows systems to authenticate users through a third party. So if I want to log into this blog, for example, I could have this blog software authenticate with Google, allowing me to use my Google account rather than some account that’s unique to this blog system.

I can then use that same Google account to authenticate with all the other OpenID capable systems out there. Now I need to only remember one password (my Google account).

This is a free/open system. You can use it however you like. No fees, no nothing.

Now immediately people will note a couple things. First, if an attacker gets the password to your OpenID account (your Google account in this instance) then he/she has access to all your accounts. Furthermore if Google goes down you won’t be able to log into anything for as long as Google’s servers are offline.

In other words it’s a single point of failure.

Furthermore, this is more for the end-user benefit than it is a benefit for those who manage these systems. Sure, you’re no longer in the business of password management, but you still must maintain a local account tied to the user’s OpenID. Systems that integrate with OpenID are still managing accounts, they’ve only saved themselves the trouble of having to set and reset passwords.

However, there is a bit of a plus side to OpenID.

You control how you authenticate.

Don’t like passwords? You can setup your own OpenID server (or, more likely, use one already in existence) that uses alternative forms of authentication. Maybe it’s biometrics, or includes some sort of CAPTCHA to defeat password guessing attempts, or maybe authentication comes in the form of answering a question that only you would have the answer to.

One really nice setup is to go through VeriSign who are OpenID Providers and will allow you to buy (for only a few dollars) an authentication token. It’s a small thing you place on your keychain and carry around with you. Whenever you go to log into the system you’ll have to include the number displayed on the token, which changes every 10-30 seconds. So even if your password is compromised you’re still fairly safe.

With OpenID this type of two-factor authentication goes with you. Any place you login with OpenID you’re using two-factor authentication. It’s brilliant.

But there’s one big problem.

A trend has started where big companies (Google, Yahoo, MSN) will allow you to use your account on their servers as an OpenID, but you cannot log into those systems with OpenID. The reason for this is that they don’t want you signing up with alternative services. If Google doesn’t do OpenID you’re forced to create a Google account. And whenever you use that Google account to log into an OpenID system you’ll have to type in “google”, helping to reinforce their name and brand in your head.

Another, more sinister, problem is that your OpenID provider will be able to track which web sites you log into and when. It would be trivial for, say, MSN to keep track of the web sites you authenticate with. Once it recognizes that you visit, say, gaming web sites, MSN might start throwing gaming advertisements at you either during your login process or while you’re on any of MSN’s own services. This sort of targeted advertising will be the excuse companies give when questioned about their tracking practices.

But who knows what else they do with that information? There’s a privacy issue here. Advocates will say it’s a moot point because if you don’t like Google’s practices you can simply switch to another OpenID provider.

That’s all well and good, but the reality is if you’re going the OpenID route you’ll want a provider that’s reliable and isn’t likely to go away in the next year or so. That means you’ll go through a large company like MSN, Google, VeriSign, etc.

There are lots of trade-offs and lots of issues to consider before taking to the OpenID highway.

Personally, I’m going to stick with a copy of KeePass and have unique, randomly generated passwords for every web site. I’ll only need to remember one password, the one to open the KeePass database, and it’s a password that won’t be stored anywhere online (not even as a hash). A side-benefit of this approach is should your system be compromised, a keylogger isn’t going to get any of your online accounts since you’re never really typing anything in (just copy/paste). So Warcraft players fear not!

The trade-off is if I ever lose that database I’m royally fucked. So backup often! A small price to pay for what I think is better security.

Static Image, Fluid Layout

Here’s a little trick that works nicely in modern browsers:

<img src="..." style="width:100%;max-width:000px;">

This image will now shrink to fit the width of the layout (width:100%) but won’t go wider than it’s own image size (max-width:000px where you replace 000 with the image’s pixel width).

Browsers should scale both X and Y even if only the X constraint (width) is set. In other words, only setting width and not height as well shouldn’t screw up the aspect ratio of the image.

The upside is images that won’t cause a fluid layout to break if the layout is narrowed to a width smaller than the image.

The downside is you can’t easily apply this rule globally. You have to either put the CSS inline for each image or you have to write a little javascript app that’ll go through every image of a with given class name, figures out the image’s max-width, and adds the max-width CSS rule on the fly.

I don’t like the javascript solution because it means a user who has it disabled will (potentially) get a broken layout. But maintaining a bunch of inline CSS is just tedious. So it’s something I’d say use, but use sparingly.

Max Width

A recent forum post about max-width in IE mentions my javascript utility library as a solution for min-width and surely someone can figure out a max-width solution as well.

Actually, I did.

If you look at the source of that javascript file you’ll see a function called set_width_limits which you can use to set both min and max width values with one function call!

set_width_limits( obj_name , min_width , max_width, ieOnly, noIE7 )

obj_name: This is the ID of the HTML element you want to apply width constraints to.
min_width: The minimum width, in pixels, that obj_name can be.
max_width: The maximum width, in pixels, that obj_name can be.
ieOnly: TRUE/FALSE; only apply this constraint to IE. Apply these constraints only in IE? Default is TRUE. The reason for this is most modern browsers understand the CSS min-width and max-width attributes. IE is really the only target for this sort of functionality. Therefore why bother putting the extra bit of overhead in having javascript control the widths of elements you can more effectively (and cleanly!) control with CSS.
noIE7: TRUE/FALSE; do not apply this code to IE7 (and later). The reason for this being that IE7 finally starts to understand CSS min/max width rules.

Skidoo Redux has the following line of javascript in its HEAD:

if ( ( typeof( set_min_width ) ).toLowerCase() != 'undefined' ) { set_min_width( 'page-container' , 600 ); }

To make use of this “new” function you could do something like this in place of the above line of code:

if ( ( typeof( set_width_limits ) ).toLowerCase() != 'undefined' ) { set_width_limits( 'page-container' , 600, 1024 ); }

And now the layout won’t expand beyond 1024 pixels in older versions of IE! You can see this in action here.

Or just look at the Bridgewater State College web site, where this function has been in use since May of this year.

Sun Java System Web Server

Sun Java System Web Server is a piece of software I’ve used for nearly 10 years now — since the days when it was called iPlanet.

Not too long ago version 7 was released. it’s free to download and use, so anyone reading this can go give it a try. I’ve been playing around with it myself so it’s on my mind and I thought I’d share a few of my feelings.

First, this is a marked improvement over previous versions. The admin interface is cleaner and more intuitive. I like the improvements they’ve made on the file structure of the thing, such as lumping the cert databases in with the configs of each server instance rather than sticking it in a separate folder. I like the concept of being able to configure a server, but not have the changes be immediately deployed. And it’s a hell of a lot better than editing a text file as is typical for the Apache user.

I don’t like the amount of options you have to help tune the server’s performance. Honestly, I’ve no idea how to properly evaluate what each variable’s (thread pools, keep alives, etc) optimal setting is. And this is even after reading the performance and tuning guide they provide with each release! It’s a bit like BMW’s iDrive. I don’t want to spend 30 minutes configuring every silly little setting on my car just so I can go down to the store and get some snacks. Just give me a few pedals, a steering wheel, and a gear shift, I don’t need to fiddle about with anything else.

But this is nothing new to 7.0. It’s been like that for quite a while. So it goes.

But the biggest worry, by far, is that I can no longer manage virtual server classes through the administrative interface.

The idea is you have multiple virtual servers. Each virtual server is, essentially, its own little web server instance. Each virtual server contains settings on what domain or ip to listen to, what directory to serve documents from, where to store logs, etc. Now there are times where you want these settings to actually be shared with multiple virtual servers. Enter the virtual server class. In 6.0 (and even earlier versions) there was a simple interface to do this.

Not any more.

You can still apply the concept of a virtual server class by manually editing the configuration files, but no longer is there an spot in the administrative interface to do all this. That’s annoying.

One other little thing that really tweaks me is on the page that lists out all the virtual servers for a given server (or administration node using the new 7.0 terminology); there’s a table and each row is a virtual server. One of the columns in the table contains a comma-delimited list of all the hosts that virtual server is set to listen for. Well they don’t put any spaces after each comma, so any virtual server with more than a couple hosts assigned to it will force the table beyond the width of your computer’s screen. In my case I have to scroll very, very, very far to the right to see everything because of this. Simply adding a space after each comma would make this particular page far more functional.

Despite all this I think 7.0 is such a huge improvement over 6.0/6.1 that I plan on migrating to this new version as soon as possible. And should I discover this to be an absolutely horrible mistake I’ll be sure to let everyone here know about it.