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
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.
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
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.
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
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