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:
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.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
That’s awesome !
So.. how can I make sure you have more free time to make more awesome apps like this? :D
Awesome
awesome
Nice work, I’ll definitely be using this in the near future!
Hmm… Awesome!
In the project I’m currently working on I found I couldn’t use django-registration, but with version 0.8 it looks like I can- great!
How about using class based views? They would seem like a cleaner way setting all the variables you can pass into the view functions, and could allow futher hooks for customization.
w00t!
Perfect timing! Just yesterday our group was talking about how to extend this for our use case.
So what we want to do is check a registration against a list. If the user’s email is on the list, proceed with your default workflow, but if not, send out an email requesting a sponsor.
Is there an easy way to do this while reusing the default workflow as much as possible?
I’ve been a follower of your blog based purely on this app when i was in college and needed it because i behind in my python class. the fact that you are redoing it is bring back all sorts of college related memory’s back.
thanks for the great app, u got me an A
“Yay” for modular Django apps with changeable backends :)
Great job James
This is great, thanks!
aw man i just spent like a whole week working on a 2 step registration that didn’t use email.
i’m on an intranet at work and i’ve made a bulletin board (essentially a multiblog). my company wants to release it globally, so i rewrote it for that purpose. instead of writing different import functions to make user accounts for every employee at each center, i decided to have users sign up, and then staff members can activate the user and deliver the user a confirmation code (to avoid employees signing up as other employees). since there is no email at most of our centers, each employee has to get their code from a staff member at their center.
in order to do this, i have to have them choose a location during registration, and the qualified members of that location, can manage the list of pending accounts. would this type of setup be possible with your app?
Superlative work, as ever. Keep it up. Despite me being a brit… ‘kudos dude!’