Skip to content

django-registration

Published on: October 14, 2009    Categories: Django, Meta

So, life has been eventful lately. There was DjangoCon, which was awesome even though I came away deeply unhappy with how my talk turned out; due to a lot of hectic things going on, it fell far below the standard I usually like to enforce for myself. I’ve got a couple things cooking for PyCon, though, which will hopefully make up for it. Things are starting to ramp up for the Django 1.2 development cycle, which is looking to be chock full of awesomeness. There’s quite a lot of interestingness going on at work which, unfortunately, I can’t really talk much about right now but which is bringing with it a general “OMG BUSY” status. And, of course, there was last week’s emergency Django security release.

What little free time I’ve had has been divided between two personal projects. One is finishing up the code repository for the second edition of Practical Django Projects (which I’d hoped to get some serious time on last weekend; the security stuff kinda crapped all over that, so I’m hoping to get back to it Saturday or Sunday, while curled up on my couch with a bunch of football games). The other is a complete rewrite of my most popular open-source application, django-registration. As luck would have it, I’ve recently been able to devote a bit of work time to it and get it nearly finished, so I’d like to take a minute to talk about that.

I’ve always tried to have django-registration offer some opportunities for customizing how users sign up, because that’s a feature which tends to have such varied requirements from site to site. There’s always been, for example, the ability to specify custom form classes, custom templates and custom redirects for actions which require them. But at its core, django-registration has always had the default workflow — two-phase register-then-activate — more or less hard-coded in, and that’s a problem: there are lots of use cases where it just doesn’t fit, and where working around django-registration’s assumptions was either difficult or impossible.

So about six months ago I quietly forked the repository and started working on a new, more flexible approach, inspired by Django’s own pluggable authentication system, which in turn owes a lot to various similar systems which preceded it. My goal was to move all the actual logic of user registration into a standard interface, then rewrite django-registration to work with anything which implements that interface.

The result, today, is the first alpha release of django-registration 0.8, which you can download from the project page at Bitbucket. A copy of the in-progress documentation is also up, and is built using Sphinx, which is frankly awesome for this. Browsing around the documentation (pay particular attention to the release notes and upgrade guide) should give you a feel for what’s new and what’s changed.

All the actual work of registering (and, optionally, activating) accounts is now handled by swappable backend classes; to plug in a new workflow, simply write a backend which implements it. The full backend API, for those of you who’d like to try your hand at it, consists of six methods, two of which are optional. Between them, I’m pretty sure they cover the whole range of things people will need or want to do with user registration. The original two-phase workflow used by older releases is now implemented as a bundled backend, and is mostly backwards-compatible: you’ll need to add one new template, and make a couple changes to one other, but aside from that things should Just Work(TM).

If you’re feeling adventurous and you’d like to try it out, grab the 0.8 alpha package and install it. Note that you’ll need to download it directly from Bitbucket, or point your favorite package-install tool at the Bitbucket URL; this package is not on PyPI and won’t be until 0.8 goes final. If you spot bugs, head on over to the issue tracker and let me know about them.

Between now and the final 0.8 release — and I don’t yet know when that’ll happen — I’ve got a few more things I’d like to get done:

  1. Adding at least one other backend bundled with django-registration, as an example of how to do that.
  2. Collecting and checking in updated translations (there are two new strings, and a few that no longer need explicit translation because they’re translated by Django itself). I’m looking at Transifex (which is both incredibly awesome, and Django-powered) as an option for making this easier all around.
  3. Expanding the documentation and smoothing out any wrinkles in the upgrade process; it isn’t 100% painless and can’t be since the changes under the hood were so big, but I suspect there’s still room for improvement.

Once it’s out the door, django-registration 0.9 will begin; I’m hoping it’ll collect fixes for any bugs which have crept through unnoticed, permanently stabilize the backend API, and provide a stepping stone toward a 1.0 release. If you’re interested in helping, feel free to grab a copy of the code from the Mercurial repo (if you have a Bitbucket account, you can just fork directly) and dive in.