User Registration Apps for Django
An important part of many web applications is creating the illusion of state on top of the stateless HTTP protocol. Although there are some naive approaches that almost work (assuming individuals with the identical IP addresses are the same, etc), at the bottom there is only one solution that works adequately: cookies.
For many applications cookie based identification--without any further identification--is sufficient1, but there also many situations where users enter important or private data, and we need to authenticate the user before allowing them access to the application and its data.
As the Django framework has grown, an ecosystem of pluggable user registration has grown as well. These registration applications all tie into the Django auth and sessions modules, and have many overlaps, but choosing the best one for your application can make your life much simpler.
Rolling Your Own Registration System
For anyone's first Django application, they will probably roll their own implementation of user registration on top of the Django auth module. There isn't anything horribly wrong with this approach, but it does violate Don't Repeat Yourself, and generally you'll end up with a less featureful and less tested solution than by using one of the pluggable backends.
If you're trying to do something novel with user registration, then this may be your only option, but generally you should only roll your own registration system when you run into a requirement that the existing registration systems cannot handle (and where patching in the needed functionality is undesirable).
django-registration
The gold standard of pluggable registration for Django
is the django-registration app.
(If you disagree, try searching for django registration. ;)
Django-registration is a very solid implementation of
a very standard registration workflow: sign up for an account,
activate account via an email, then log in.
For many sites, plugging in django-registration is the easiest and most complete approach to implementing registration in your app. The one piece of functionality it doesn't support out of the box is OpenID authentication.
It is certainly possible to integrate OpenID support into django-registration, and that is a reasonable solution, although it requires a bit of mental energy2.
django-openid
If you want your site to support OpenID, then django-openid is your Rome. Or, at minimum, it is the foundation your Rome was built upon. Django-openid is a close parallel to the Django auth module. It provides the underlying support for performing user authentication via OpenID, but you'll end up writing a bit of custom code to integrate it into your application.
If you're only interested in supporting OpenID, then this is probably the solution you'll want to use. If you're really deadset on using django-registration and still want OpenID, then this is also the tool you'll want to accomplish that.
django-authopenid
The last registration solution I'll mention is django-authopenid. It provides plugin support for both OpenID and traditional authentication, and for that reason it is a very attractive choice. Recently I have taken to using django-authopenid for my projects, and it has my hearty endorsement.
That said, it is not as polished as django-registration,
and even though it'll plug in and work out of the box, you'll almost certainly
end up rewriting its templates for your purposes (in particular, I think
that the fieldset element doesn't provide a consistent crossbrowser
experience). Additionally, it doesn't require users to verify their
email with an authentication email like django-registration does, which
may a feature you feel is important.
For whatever roughness it has, it provides account management out of the box, provides functionality for associating OpenID logins with existing accounts or for creating new accounts for OpenID logins, and is an excellent tool if you're willing to tweak it ever-so-slightly for your needs.
Are there any other pluggable registration apps that I should have mentioned?
I think that we've begun to see gradual improvement in this respect. More and more web applications are acknowledging the poor user interface created by mandating using registration and login, and are attempting to minimize or avoid registration/login completely. I hope the trend continues, but I'm even more hopeful we can find a compromise that allows a good user experience and still allows sites to perform some meaningful identity authentication.↩
The whole OpenID can of words is both befuddling and bewildering. When Stackoverflow went live and became one of the few sites to only support OpenID, it was impressive to see a vocal minority of professional developers who were upset about having to use OpenID. This is scary, because professional developers are likely the group with the highest penetration of OpenID awareness. (Compared to Yahoo's research on OpenID awareness for the public, which essentially revealed that very few people have a clue what OpenID is.
On the other side, there are OpenID fanatics who get equally upset about sites which require yet another login. If you can only support OpenID or non-OpenID, then clearly supporting OpenID is a suicidal choice unless your userbase is developers, and possibly a bad choice no matter what.
For the time being, supporting both OpenID and traditional registration seems like the appropriate decision. However, as additional OpenID-like services sprout up, it'll further balkanize universal login services, and it'll become increasingly awkward to support all of them. It'll be an interesting area to watch.↩