With all this buzz about OpenID all of a sudden I have been reminded of how a while back I was tinkering with a TurboGears-based web game using OpenID (see parts 1, 2, 3). Having learned more about WSGI and Python Paste I am inclined to see how far I can push the idea of writing web applications using WSGI and a collection of WSGI filters as my framework.

WSGI and WSGI filters

The WSGI approach uses a Python callable to represent a web application---or part of one, since WSGI apps can be composed in various ways to make more complicated apps. An app is a function with a definition like this:

def something_app(environ, start_response):
    ...examine environ and process request...

    start_response('200 OK', headers)
    return ...content of response...

When the web server receives a request, it puts the information about the request in environ, calls something_app, and then uses its return value and the headers passed to the start_response function to issue the response to the caller.

WSGI is designed to be used as a common interface for web frameworks, but given that it has to pass the information in environ to the application code in some way, the environ dictionary is as good a way as any. Similarly, your application has to provide the server with status code, headers, and response data, and the start_response callable is as good away to do that as any. So why not use WSGI as your framework? Because your application would have to have its own code for decoding query-strings, setting cookies, and so on, which would mean a lot of tedious repeated code. But we can address this with filters.

A WSGI filter is a (higher-order) function that takes a WSGI app and returns a new app with slightly modified behaviour. For example, WSGI supplies your request's query-string but does not break it down in to parameters. I've created a function parse_query_string that does just that. I can then define a filter as follows:

def query_string_filter(app):
    def wrapped_app(environ, start_response):
        environ['alleged.query_args'] = parse_query_string(
                environ.get('QUERY_STRING', ''))
        return app(environ, start_response)
    return wrapped_app

This takes a function---here called app---that requires an extra entry in the environ dictionary and makes a working WSGI app. Python has a special syntax for applying functions to functions this way: you can write

@query_string_filter
def my_app(environ, start_response):
    ... code that exploits environ['alleged.query_args'] ...

This use of higher-order functions to simplify writing WSGI apps is called middleware in the WSGI documentation.

Why does the key start with alleged.? Simply to avoid name clashes with other middleware that also works by adding extra entries to the environ dictionary. The particular prefix I've chosen is taken from Alleged Literature, our mini-comic publishing imprint from the 1990s. The alleged prefix is also part of the package names for the reusable filters. I suppose if I ever finished it I could add the Alleged Microframework to the eleventy-one Python web frameworks. But don't hold your breath.

Log-in filter

One of the complaints about OpenID is that so far the number of consumers (web sites that allow you to log in with your OpenID) is much lower than the number of providers---this is natural, because it is much easier to bolt an OpenID server on the side of an existing application than to rip out its custom user database and replace it with one generic enough to accept OpenIDs as well. The first wave of OpenID consumers will be applications written with OpenID in mind from the start. Many, like Zoomr and Simon Willison's blog comments, use OpenID as their only authentication scheme. So I decided to have a go at making a log-in system with pluggable authentication, but to only supply an OpenID plug-in for now.

My log-in 'framework' (if that's not too grand a word) consists of just two functions. First, log_in_filter is a more elaborate version of the filter (middleware) functions described above. It roughly corresponds to Part 2 of my TurboGears+OpenID experiment: the wrapped app checks for the log-in cookie before each request, and if no-one is logged in then it redirects to a login page (with one exception: you do not need to be logged in to visit the login page). At the end of each request, it updates the log-in cookie.

The second function, log_in_and_redirect, is for use by the implementation of the log-in page: it takes the user name as an argument, and redirects to the page that the user originally requested. You call it instead of calling start_response directly.

What's missing from this is the log-in page itself: it must be one of the pages in the wrapped app, because it has to be able to communicate the user's login name back to log_in_filter. It also has to be careful to preserve the query-string parameter next; the most straightforward way to do this is to have the log-in form use request_uri(environ) as its action attribute and also specify method="post".

Leaving the log-in page to the application allows any form of user name and authentication to be used, including elaborate single-sign-on servers and exotic smart-cards. Because the log_in_filter does not need to know anything about the method of authentication, it needs a lot less configuration than it might otherwise do.

Plugging in OpenID

The next step is creating a log-in page that works via OpenID. So far I have taken the code from Part 1 of my TurboGears version and beaten it roughly in to shape. Unlike the TurboGears version---which used separate URIs for each stage of the OpenID handshake---it uses the same login URI for displaying the form, handling the user's POST, and handling the redirect back from the OpenID provider. The first and last of these are implementing the same method (GET) but we can tell the which is which by looking for the token argument amongst the query parameters.

Unfortunately I have not yet been able to test this, since I have not yet managed to get Pysqlite2 (needed to set up the OpenID database) installed in Python 2.5 on my Mac as yet: I get an error message to the effect that GCC 4.0 does not exist, so it looks like I need to trawl through the Apple developer documentation to see what I need to do to get the compiler to work. Grr.

Ah well. Maybe next weekend...?

Author
X
Published
18 February
Topics