django-registration / docs / default-backend.rst

Full commit

The default backend

A default registration backend` is bundled with django-registration, as the module registration.backends.default, and implements a simple two-step workflow in which a new user first registers, then confirms and activates the new account by following a link sent to the email address supplied during registration.

Default behavior and configuration

To make use of this backend, simply include the URLConf registration.backends.default.urls at whatever location you choose in your URL hierarchy.

This backend makes use of the following settings:

This is the number of days users will have to activate their accounts after registering. Failing to activate during that period will leave the account inactive (and possibly subject to deletion). This setting is required, and must be an integer.
A boolean (either True or False) indicating whether registration of new accounts is currently permitted. This setting is optional, and a default of True will be assumed if it is not supplied.

By default, this backend uses :class:`registration.forms.RegistrationForm` as its form class for user registration; this can be overridden by passing the keyword argument form_class to the :func:`~registration.views.register` view.

Two views are provided: registration.backends.default.views.RegistrationView and registration.backends.default.views.ActivationView. These views subclass django-registration's base :class:`~registration.views.RegistrationView` and :class:`~registration.views.ActivationView`, respectively, and implement the two-step registration/activation process.

Upon successful registration -- not activation -- the default redirect is to the URL pattern named registration_complete; this can be overridden in subclasses by changing :attr:`~registration.views.RegistrationView.success_url` or implementing :meth:`~registration.views.RegistrationView.get_success_url()`

Upon successful activation, the default redirect is to the URL pattern named registration_activation_complete; this can be overridden in subclasses by implementing :meth:`~registration.views.ActivationView.get_success_url()`.

How account data is stored for activation

During registration, a new instance of django.contrib.auth.models.User is created to represent the new account, with the is_active field set to False. An email is then sent to the email address of the account, containing a link the user must click to activate the account; at that point the is_active field is set to True, and the user may log in normally.

Activation is handled by generating and storing an activation key in the database, using the following model:

A simple representation of the information needed to activate a new user account. This is not a user profile; it simply provides a place to temporarily store the activation key and determine whether a given account has been activated.

Has the following fields:

Additionally, one class attribute exists:

And the following methods:

Additionally, :class:`RegistrationProfile` has a custom manager (accessed as RegistrationProfile.objects):

This manager provides several convenience methods for creating and working with instances of :class:`RegistrationProfile`: