An Authentication Framework

Authentication baked into the framework

All the frameworks I’ve looked at have poor authentication support. Some don’t have an authentication framework at all. Some support HTTP Basic Auth or HTTP Digest Auth. Others support form-based login withought HTTP auth.

Using form-based authentication is preferred for Web applications because you have complete control over the user experience. You can change the appearance of the login form; you can change the number and type of input fields; you can do anything.

HTTP Authentication has the advantage of simplicity. You can use HTTP auth to secure a folder on your Web server with only a few configuration parameters. You also have a surprising amount of flexibility with HTTP auth: your user records can be stored in a DB or in LDAP or in a flat file.

Authentication in an Ajax world

I’ve been working with TurboGears lately to build out the server-side of the CMS. One of TurboGear’s halmark features is the ability to seamlessly return either XHTML or Javascript objects in JSON format. That’s huge if you’re working with Ajax like I am. When you combine the JSON data with my DHTML Bindings Framework, you’ve got a really powerful toolset.

Ajax demands greater flexibility from authentication frameworks.

If you’re using Ajax with form-based authentication, what do you do if the user’s session expires and you need to redirect him to a login screen? I suppose you could send the HTML for the login screen back instead of JSON formatted objects, but your client-side code would have to be very smart.

Ideally, when building an Ajax application, you would respond with an HTML form for authentication when the browser requests an HTML page and an HTTP authentication error code when the browser uses an XMLHttpRequest to fetch a resource.

Form-based Authentication
Ajax Authentication
It’s no secret that I’m not a fan of any of the big free (or reasonably free, like [MovableType](http://www.sixapart.com/movabletype/)) content management systems. They all lack something. Possibly, what they really lack is the key ingredient that [37signals](http://www.37signals.com/) has added to all of their products: simplicity. I’m going to build my own content management system. I’ll join the horde of open source (I suspect) CMSs. But I hope to be different, however, I’m not going to give away my secrets now. Now I want to talk about authentication for Web applications. #### Authentication baked into the framework #### All the frameworks I’ve looked at have poor authentication support. Some don’t have an authentication framework at all. Some support HTTP Basic Auth or HTTP Digest Auth. Others support form-based login withought HTTP auth. Using form-based authentication is preferred for Web applications because you have complete control over the user experience. You can change the appearance of the login form; you can change the number and type of input fields; you can do anything. HTTP Authentication has the advantage of simplicity. You can use HTTP auth to secure a folder on your Web server with only a few configuration parameters. You also have a surprising amount of flexibility with HTTP auth: your user records can be stored in a DB or in LDAP or in a flat file. #### Authentication in an Ajax world #### I’ve been working with [TurboGears](http://www.turbogears.org) lately to build out the server-side of the CMS. One of TurboGear’s halmark features is the ability to seamlessly return either XHTML or Javascript objects in [JSON](http://www.json.org/) format. That’s huge if you’re working with Ajax like I am. When you combine the JSON data with my [DHTML Bindings Framework](http://metrocat.org/nerd/2005/08/dhtml-binding-example), you’ve got a *really* powerful toolset. Ajax demands greater flexibility from authentication frameworks. If you’re using Ajax with form-based authentication, what do you do if the user’s session expires and you need to redirect him to a login screen? I suppose you could send the HTML for the login screen back instead of JSON formatted objects, but your client-side code would have to be *very* smart.
Form-based Authentication

Form-based Authentication

Ideally, when building an Ajax application, you would respond with an HTML form for authentication when the browser requests an HTML page and an HTTP authentication error code when the browser uses an XMLHttpRequest to fetch a resource.

Ajax Authentication

Ajax Authentication

Sadly, none of the existing authentication frameworks seem to support this model. Of course, I could write a custom framework and plug it into TurboGears. But I’m rather hoping the unique nature of TurboGears encourages someone to build (or extend) a framework which supports both form-based and HTTP header-based authentication schemes.

I may be too optimistic.

Possibly Related

Comments

cbd October 5th, 2005 @ 9:09 pm

You’re writing a CMS. Very good. I hope you’ll pay more attention to web accessibility than most. I’m discovering more and more problems with the big commercial education-specific CMS (WebCT, Blackboard) but think the big names in FLOSS aren’t much better.

TIm Howland October 7th, 2005 @ 6:31 pm

Too cool, another geek in Newburyport- I just moved here in May from Connecticut (sold the house to start a webops support company for interactive agencies).

I’ve got a fair amount of experience with many of the big commercial CMS offerings, and can say that they are all less than great- eventually, the marketing department just gives up and starts emailing word documents to the IT staff- the most junior guy at the BigCo’s IT department ends up being the only one using the $150,000 CMS… I much prefer working with the free stuff - I’ve used OpenCMS on a bunch of them with fair to middling success. I don’t see why you wouldn’t use this or a similar open source product (or write your own- python isn’t my bag, but the turbogears demo was pretty cool looking).

I’ve also been thinking about the opportunities that AJAX-style development offers portals. Specifically, I’ve been contemplating building a whole javascript window manager- capable of handling independent windows, Z-ordering, iconifying, and so on- all the content calls would go through an XML proxy on the server, so you could rewrite foreign content on the way by- letting you host multiple independent windows on screen from multiple content sources.

This means you could have portals break away from the windows 1.0 style of tiled display areas, and move them to true windowing systems (finally catching up with mac circa 1984!).

Of course, you also have to handle the authentication / session problem in this kind of system; there are really two options:

1) A background thread that keeps making background keepalive requests as long as the admin window is open (expensive, but most CMS’s don’t have that many users). You could throw up a javascript lock dialog, and close the session after some timeout period.

2) A sophisticated Freeze / Thaw system- you put a destructor in there when the session gets torn down, and persist everything to disk, then you thaw it out when a client shows up with a cookie containing a hashed GUID that matches your lookup table…

(I think I’d do the first one)…

I haven’t met any other computer folks in the area, want to get together at the Grog and trade war stories sometime? Email me at th@wdogsystems.com if you do-

Tim