The auth module provides a set of functions to handle basic operations involving user accounts. There are built-in views that you can use to allow users to log in, log out, and reset passwords. There are also forms included in the auth module that you can use for similar functionality. One such form is the UserCreationForm, which provides a very simple mechanism to create new user accounts.

The built-in views and forms are very useful, but somewhat low-level. There is a lot of functionality you must provide yourself if you intend to use them. You could also write your own forms and views to handle these operations, especially if you need some custom functionality. Generally, though, it's best not to repeat ourselves. If code already exists, and looks like it will meet our needs, then we should try using it first.

The ultimate example of this is the community of third-party applications that exist for Django. Sometimes these exist as a small snippet of code on djangosnippets.org. Other times these are fully-fledged open source projects with multiple contributors and their own homepage.

One such larger project is django-registration, a reusable Django application designed to provide several convenient functions for handling new user creation. This registration app was created by James Bennett, the current Django release manager, and it is very popular and widely used. The current version of the project, with installation instructions, is available at this URL: http://bitbucket.org/ubernostrum/django-registration/wiki/Home.

After installing the registration app, as with any well-written third-party Django app, adding it to your project is very simple. Simply update the INSTALLED_APPS setting in your settings file by adding an entry for 'registration'. Once added to your settings, you can run syncdb to create the necessary tables. Django-registration uses a few extra models to manage the current state of a user registration.

For example, when a user signs up for an account, it creates a new User object and then sends them an e-mail to verify their e-mail address. Until the link provided in this e-mail is clicked, the new User object is marked as inactive and cannot be used for logging in. This behavior is customizable, of course, but it is recommended that you verify e-mail addresses of new user accounts to prevent spam or other fraudulent account creations.

There are currently a few competing philosophies around how to build and distribute third-party Django applications. It doesn't make sense, often, to include things such as templates in a third-party utility, because every developer will require customization to these templates. Instead, projects are often designed with default template names in their included views. These default templates are not included with the app, but can quickly be built by the developer for their project and the app views will automatically locate them. This is very similar to the way generic views worked in the previous chapter.

If you prefer to get up and running quickly, you can simply add an entry for the default URLs file, included with the registration app, to your root URLs. This would look something like this (on registration v0.8):

(r'^accounts/', include('registration.backends.default.urls')),

This will automatically create URL patterns for the views exposed by django-registration. These include a register view and an account verification view. For example, if you included the above URL pattern in your root URLs, the registration view will be at /accounts/register/.

The register view is the main view in the registration app. This view and all the others are described in detail in the registration documentation. We will only discuss the register view here. By default the register view renders a template called registration/registration_form.html and provides this template with a context variable called form. The form variable is an instance of the RegistrationForm class, which is included in the app. This form provides all the necessary fields to create an account. These fields include: username, e-mail, and two fields to verify a password.

It is possible to substitute your own form class for the default RegistrationForm returned by the register view. To do this, you will need to add a custom URL pattern for the register view and provide a view parameter called form_class, which points to a Python class to use as the form. For example, to add a custom form to the register view, but keep all other registration views at their defaults, you could modify the above URL pattern like so:

(r'^accounts/register/$', 'registration.views.register',
 {'form_class': MyRegistrationForm}),
(r'^accounts/', include('registration.backends.default.urls')),

By placing the custom URL pattern ahead of the defaults, we can override registration's built-in register view. We've also instructed the register view to use our own registration form instead of the default. Note also that each view in the registration app has many parameters to override. Another useful example is the template_name parameter, which can be changed to use your own template instead of the default registration/registration_form.html.

Generally, when creating a custom registration form, you will want to inherit from registration's default RegistrationForm and add your own fields. The registration app also includes some additional registration forms with added functionality, which you can use as examples when writing your own.

Using django-registration to allow your users to create accounts is completely optional. We could spend time implementing our own approach to this problem, but as we've seen that the flexibility provided by this particular third-party tool is enough to allow many customizations. We have only scratched the surface of the available customizations in this app, so it is highly recommended you explore the documentation further to see all that it can do.