Base view classes

In order to allow the utmost flexibility in customizing and supporting different workflows, django-registration makes use of Django’s support for class-based views. Included in django-registration are two base classes which can be subclassed to implement many types of registration workflows.

The built-in workflows in django-registration provide their own subclasses of these views, and the documentation for those workflows will indicate customization points specific to those subclasses. The following reference covers useful attributes and methods of the base classes, for use in writing your own custom registration workflows.

class django_registration.views.RegistrationView

A subclass of Django’s FormView which provides the infrastructure for supporting user registration.

Standard attributes and methods of FormView can be overridden to control behavior as described in Django’s documentation, with the exception of get_success_url(), which must use the signature documented below.

When writing your own subclass, one method is required:

register(form)

Implement your registration logic here. form will be the (already-validated) form filled out by the user during the registration process (i.e., a valid instance of RegistrationForm or a subclass of it).

This method should return the newly-registered user instance, and should send the signal django_registration.signals.user_registered. Note that this is not automatically done for you when writing your own custom subclass, so you must send this signal manually.

Parameters

form (django_registration.forms.RegistrationForm) – The registration form to use.

Return type

django.contrib.auth.models.AbstractUser

Useful optional places to override or customize on subclasses are:

disallowed_url

The URL to redirect to when registration is disallowed. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Default value is the result of calling reverse_lazy() with the URL name ‘registration_disallowed’.

form_class

The form class to use for user registration. Can be overridden on a per-request basis (see below). Should be the actual class object; by default, this class is django_registration.forms.RegistrationForm.

success_url

The URL to redirect to after successful registration. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Can be overridden on a per-request basis (see below). Default value is None; subclasses must override and provide this.

template_name

The template to use for user registration. Should be a string. Default value is ‘django_registration/registration_form.html’.

get_form_class()

Select a form class to use on a per-request basis. If not overridden, will use form_class. Should be the actual class object.

Return type

django_registration.forms.RegistrationForm

get_success_url(user)

Return a URL to redirect to after successful registration, on a per-request or per-user basis. If not overridden, will use success_url. Should return a value of the same type as success_url (see above).

Parameters

user (django.contrib.auth.models.AbstractUser) – The new user account.

Return type

str

registration_allowed()

Should indicate whether user registration is allowed, either in general or for this specific request. Default value is the value of the setting REGISTRATION_OPEN.

Return type

bool

class django_registration.views.ActivationView

A subclass of Django’s TemplateView which provides support for a separate account-activation step, in workflows which require that.

One method is required:

activate(*args, **kwargs)

Implement your activation logic here. You are free to configure your URL patterns to pass any set of positional or keyword arguments to ActivationView, and they will in turn be passed to this method.

This method should return the newly-activated user instance (if activation was successful), or raise ActivationError (if activation was not successful).

Return type

django.contrib.auth.models.AbstractUser

Raises

django_registration.exceptions.ActivationError – if activation fails.

Useful places to override or customize on an ActivationView subclass are:

success_url

The URL to redirect to after successful activation. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Can be overridden on a per-request basis (see below). Default value is None; subclasses must override and provide this.

template_name

The template to use after failed user activation. Should be a string. Default value is ‘django_registration/activation_failed.html’.

get_success_url(user)

Return a URL to redirect to after successful activation, on a per-request or per-user basis. If not overridden, will use success_url. Should return a value of the same type as success_url (see above).

Parameters

user (django.contrib.auth.models.AbstractUser) – The activated user account.

Return type

str