--- /srv/rebuilderd/tmp/rebuilderddhWBjQ/inputs/python-django-registration-doc_3.3-1_all.deb +++ /srv/rebuilderd/tmp/rebuilderddhWBjQ/out/python-django-registration-doc_3.3-1_all.deb ├── file list │ @@ -1,3 +1,3 @@ │ -rw-r--r-- 0 0 0 4 2022-10-24 11:30:38.000000 debian-binary │ --rw-r--r-- 0 0 0 2048 2022-10-24 11:30:38.000000 control.tar.xz │ --rw-r--r-- 0 0 0 58628 2022-10-24 11:30:38.000000 data.tar.xz │ +-rw-r--r-- 0 0 0 2044 2022-10-24 11:30:38.000000 control.tar.xz │ +-rw-r--r-- 0 0 0 58144 2022-10-24 11:30:38.000000 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── ./control │ │ │ @@ -1,13 +1,13 @@ │ │ │ Package: python-django-registration-doc │ │ │ Source: python-django-registration │ │ │ Version: 3.3-1 │ │ │ Architecture: all │ │ │ Maintainer: Debian Python Team │ │ │ -Installed-Size: 530 │ │ │ +Installed-Size: 516 │ │ │ Depends: libjs-sphinxdoc (>= 4.3), sphinx-rtd-theme-common (>= 1.0.0+dfsg) │ │ │ Section: doc │ │ │ Priority: optional │ │ │ Homepage: https://github.com/ubernostrum/django-registration │ │ │ Description: User-registration application for Django (Documentation) │ │ │ This is a fairly simple user-registration application for Django, │ │ │ designed to make allowing user signups as painless as possible. │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ ├── data.tar.xz │ ├── data.tar │ │ ├── file list │ │ │ @@ -29,35 +29,35 @@ │ │ │ -rw-r--r-- 0 root (0) root (0) 420 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/documentation_options.js │ │ │ -rw-r--r-- 0 root (0) root (0) 286 2021-01-01 06:53:29.000000 ./usr/share/doc/python-django-registration-doc/html/_static/file.png │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/fonts/ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/js/ │ │ │ -rw-r--r-- 0 root (0) root (0) 90 2021-01-01 06:53:29.000000 ./usr/share/doc/python-django-registration-doc/html/_static/minus.png │ │ │ -rw-r--r-- 0 root (0) root (0) 90 2021-01-01 06:53:29.000000 ./usr/share/doc/python-django-registration-doc/html/_static/plus.png │ │ │ -rw-r--r-- 0 root (0) root (0) 4846 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/pygments.css │ │ │ --rw-r--r-- 0 root (0) root (0) 31041 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/activation-workflow.html │ │ │ --rw-r--r-- 0 root (0) root (0) 24440 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/custom-user.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 28634 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/activation-workflow.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 22513 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/custom-user.html │ │ │ -rw-r--r-- 0 root (0) root (0) 6358 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/deprecations.html │ │ │ --rw-r--r-- 0 root (0) root (0) 9471 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/exceptions.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 9113 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/exceptions.html │ │ │ -rw-r--r-- 0 root (0) root (0) 26640 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/faq.html │ │ │ --rw-r--r-- 0 root (0) root (0) 15910 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/forms.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 15392 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/forms.html │ │ │ -rw-r--r-- 0 root (0) root (0) 19982 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/genindex.html │ │ │ -rw-r--r-- 0 root (0) root (0) 9525 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/index.html │ │ │ -rw-r--r-- 0 root (0) root (0) 9880 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/install.html │ │ │ -rw-r--r-- 0 root (0) root (0) 1423 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/objects.inv │ │ │ -rw-r--r-- 0 root (0) root (0) 13312 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/one-step-workflow.html │ │ │ -rw-r--r-- 0 root (0) root (0) 7726 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/py-modindex.html │ │ │ --rw-r--r-- 0 root (0) root (0) 29119 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/quickstart.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 27745 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/quickstart.html │ │ │ -rw-r--r-- 0 root (0) root (0) 5476 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/search.html │ │ │ -rw-r--r-- 0 root (0) root (0) 22435 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/searchindex.js │ │ │ --rw-r--r-- 0 root (0) root (0) 16620 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/security.html │ │ │ --rw-r--r-- 0 root (0) root (0) 10684 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/settings.html │ │ │ --rw-r--r-- 0 root (0) root (0) 11471 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/signals.html │ │ │ --rw-r--r-- 0 root (0) root (0) 34684 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/upgrade.html │ │ │ --rw-r--r-- 0 root (0) root (0) 28051 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/validators.html │ │ │ --rw-r--r-- 0 root (0) root (0) 25360 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/views.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 16426 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/security.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 10324 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/settings.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 11165 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/signals.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 32540 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/upgrade.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 26617 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/validators.html │ │ │ +-rw-r--r-- 0 root (0) root (0) 22742 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/views.html │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc-base/ │ │ │ -rw-r--r-- 0 root (0) root (0) 440 2022-10-24 11:30:38.000000 ./usr/share/doc-base/python-django-registration-doc.django-registration-overview │ │ │ lrwxrwxrwx 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/css/badge_only.css -> ../../../../../sphinx_rtd_theme/static/css/badge_only.css │ │ │ lrwxrwxrwx 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/css/theme.css -> ../../../../../sphinx_rtd_theme/static/css/theme.css │ │ │ lrwxrwxrwx 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/doctools.js -> ../../../../javascript/sphinxdoc/1.0/doctools.js │ │ │ lrwxrwxrwx 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/fonts/Lato-Bold.ttf -> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf │ │ │ lrwxrwxrwx 0 root (0) root (0) 0 2022-10-24 11:30:38.000000 ./usr/share/doc/python-django-registration-doc/html/_static/fonts/Lato-Bold.woff2 -> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 │ │ ├── ./usr/share/doc/python-django-registration-doc/html/activation-workflow.html │ │ │ @@ -101,15 +101,15 @@ │ │ │ django_registration.backends.activation, implements a two-step │ │ │ registration process: a user signs up, an inactive account is created, │ │ │ and an email is sent containing an activation link which must be │ │ │ clicked to make the account active.

│ │ │
│ │ │

Behavior and configuration

│ │ │

A default URLconf is provided, which you can │ │ │ -include() in your URL configuration; that URLconf │ │ │ +include() in your URL configuration; that URLconf │ │ │ is django_registration.backends.activation.urls. For example, to │ │ │ place user registration under the URL prefix /accounts/, you could │ │ │ place the following in your root URLconf:

│ │ │ 
from django.urls import include, path
│ │ │  
│ │ │  urlpatterns = [
│ │ │      # Other URL patterns ...
│ │ │ @@ -159,57 +159,57 @@
│ │ │  form instance passed from
│ │ │  register().

│ │ │  

│ │ │  
Parameters

│ │ │  
form (django_registration.forms.RegistrationForm) – The registration form.

│ │ │  

│ │ │  
Return type

│ │ │ -
django.contrib.auth.models.AbstractUser

│ │ │ +
django.contrib.auth.models.AbstractUser

│ │ │  

│ │ │  

│ │ │  
│ │ │  
│ │ │  

│ │ │  

│ │ │  get_activation_key(user)

│ │ │  
Given an instance of the user model, generates and returns an
│ │ │  activation key (a string) for that user account.

│ │ │  

│ │ │  
Parameters

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

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

│ │ │  

│ │ │  
Return type

│ │ │ -
str

│ │ │ +
str

│ │ │  

│ │ │  

│ │ │  

│ │ │  
│ │ │  

│ │ │  

│ │ │  get_email_context(activation_key)

│ │ │  
Returns a dictionary of values to be used as template context
│ │ │  when generating the activation email.

│ │ │  

│ │ │  
Parameters

│ │ │ -
activation_key (str) – The activation key for the new user account.

│ │ │ +
activation_key (str) – The activation key for the new user account.

│ │ │  

│ │ │  
Return type

│ │ │ -
dict

│ │ │ +
dict

│ │ │  

│ │ │  

│ │ │  

│ │ │  
│ │ │  

│ │ │  

│ │ │  send_activation_email(user)

│ │ │  
Given an inactive user account, generates and sends the
│ │ │  activation email for that account.

│ │ │  

│ │ │  
Parameters

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

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

│ │ │  

│ │ │  
Return type

│ │ │  
None

│ │ │  

│ │ │  

│ │ │  

│ │ │  
│ │ │ @@ -258,24 +258,24 @@
│ │ │  

│ │ │  get_user(username)

│ │ │  
Given a username (determined by the activation key), looks up
│ │ │  and returns the corresponding instance of the user model. If no
│ │ │  such account exists, raises
│ │ │  ActivationError as
│ │ │  described above. In the base implementation, checks the
│ │ │ -is_active field to
│ │ │ +is_active field to
│ │ │  avoid re-activating already-active accounts, and raises
│ │ │  ActivationError with code
│ │ │  already_activated to indicate this case.

│ │ │  

│ │ │  
Parameters

│ │ │ -
username (str) – The username of the new user account.

│ │ │ +
username (str) – The username of the new user account.

│ │ │  

│ │ │  
Return type

│ │ │ -
django.contrib.auth.models.AbstractUser

│ │ │ +
django.contrib.auth.models.AbstractUser

│ │ │  

│ │ │  
Raises

│ │ │  
django_registration.exceptions.ActivationError – if no
│ │ │  matching inactive user account exists.

│ │ │  

│ │ │  

│ │ │  

│ │ │ @@ -288,18 +288,18 @@
│ │ │  specified in the setting ACCOUNT_ACTIVATION_DAYS, and
│ │ │  returns the username from the activation key. Raises
│ │ │  ActivationError, as
│ │ │  described above, if the activation key has an invalid signature
│ │ │  or if the timestamp is too old.

│ │ │  

│ │ │  
Parameters

│ │ │ -
activation_key (str) – The activation key for the new user account.

│ │ │ +
activation_key (str) – The activation key for the new user account.

│ │ │  

│ │ │  
Return type

│ │ │ -
str

│ │ │ +
str

│ │ │  

│ │ │  
Raises

│ │ │  
django_registration.exceptions.ActivationError – if the
│ │ │  activation key has an invalid signature or is expired.

│ │ │  

│ │ │  

│ │ │  
│ │ │ @@ -308,15 +308,15 @@
│ │ │  
Note

│ │ │  
URL patterns for activation

│ │ │  
Although the actual value used in the activation key is the new
│ │ │  user account’s username, the URL pattern for
│ │ │  ActivationView does not need to match all
│ │ │  possible legal characters in a username. The activation key that
│ │ │  will be sent to the user (and thus matched in the URL) is
│ │ │ -produced by django.core.signing.dumps(), which
│ │ │ +produced by django.core.signing.dumps(), which
│ │ │  base64-encodes its output. Thus, the only characters this
│ │ │  pattern needs to match are those from the URL-safe base64
│ │ │  alphabet, plus
│ │ │  the colon (”:”) which is used as a separator.

│ │ │  
The default URL pattern for the activation view in
│ │ │  django_registration.backends.activation.urls handles this for
│ │ │  you.

│ │ │ @@ -324,28 +324,28 @@
│ │ │  
│ │ │  
│ │ │
│ │ │
│ │ │

How it works

│ │ │

When a user signs up, the activation workflow creates a new user │ │ │ instance to represent the account, and sets the is_active field to │ │ │ -False. It then sends an email to the address provided during │ │ │ +False. It then sends an email to the address provided during │ │ │ signup, containing a link to activate the account. When the user │ │ │ -clicks the link, the activation view sets is_active to True, │ │ │ +clicks the link, the activation view sets is_active to True, │ │ │ after which the user can log in.

│ │ │

The activation key is the username of the new account, signed using │ │ │ Django’s cryptographic signing tools │ │ │ -(specifically, dumps() is used, to │ │ │ +(specifically, dumps() is used, to │ │ │ produce a guaranteed-URL-safe value). The activation process includes │ │ │ verification of the signature prior to activation, as well as │ │ │ verifying that the user is activating within the permitted window (as │ │ │ specified in the setting │ │ │ ACCOUNT_ACTIVATION_DAYS, mentioned │ │ │ above), through use of Django’s │ │ │ -TimestampSigner.

│ │ │ +TimestampSigner.

│ │ │
│ │ │
│ │ │

Security considerations

│ │ │

The activation key emailed to the user in the activation workflow │ │ │ is a value obtained by using Django’s cryptographic signing tools. The │ │ │ activation key is of the form:

│ │ │ 
encoded_username:timestamp:signature
│ │ │ ├── html2text {}
│ │ │ │ @@ -31,15 +31,15 @@
│ │ │ │  ===============================================================================
│ │ │ │  ************ TThhee ttwwoo--sstteepp aaccttiivvaattiioonn wwoorrkkffllooww_?¶ ************
│ │ │ │  The two-step activation workflow, found
│ │ │ │  indjango_registration.backends.activation, implements a two-step registration
│ │ │ │  process: a user signs up, an inactive account is created, and an email is sent
│ │ │ │  containing an activation link which must be clicked to make the account active.
│ │ │ │  ********** BBeehhaavviioorr aanndd ccoonnffiigguurraattiioonn_?¶ **********
│ │ │ │ -A default URLconf is provided, which you can _i_n_c_l_u_d_e_(_) in your URL
│ │ │ │ +A default URLconf is provided, which you can include() in your URL
│ │ │ │  configuration; that URLconf isdjango_registration.backends.activation.urls. For
│ │ │ │  example, to place user registration under the URL prefix/accounts/, you could
│ │ │ │  place the following in your root URLconf:
│ │ │ │  from django.urls import include, path
│ │ │ │  
│ │ │ │  urlpatterns = [
│ │ │ │      # Other URL patterns ...
│ │ │ │ @@ -73,36 +73,36 @@
│ │ │ │              _s_e_n_d___a_c_t_i_v_a_t_i_o_n___e_m_a_i_l_(_) to send the email with the activation key.
│ │ │ │              The argumentformis a valid registration form instance passed from
│ │ │ │              _r_e_g_i_s_t_e_r_(_).
│ │ │ │                Parameters
│ │ │ │                    ffoorrmm (_dd_jj_aa_nn_gg_oo____rr_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_.._ff_oo_rr_mm_ss_.._RR_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_FF_oo_rr_mm) – The
│ │ │ │                    registration form.
│ │ │ │                Return type
│ │ │ │ -                  _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_u_t_h_._m_o_d_e_l_s_._A_b_s_t_r_a_c_t_U_s_e_r
│ │ │ │ +                  django.contrib.auth.models.AbstractUser
│ │ │ │          get_activation_key(uusseerr)_¶
│ │ │ │              Given an instance of the user model, generates and returns an
│ │ │ │              activation key (a string) for that user account.
│ │ │ │                Parameters
│ │ │ │ -                  uusseerr (_dd_jj_aa_nn_gg_oo_.._cc_oo_nn_tt_rr_ii_bb_.._aa_uu_tt_hh_.._mm_oo_dd_ee_ll_ss_.._AA_bb_ss_tt_rr_aa_cc_tt_UU_ss_ee_rr) – The new user
│ │ │ │ +                  uusseerr (ddjjaannggoo..ccoonnttrriibb..aauutthh..mmooddeellss..AAbbssttrraaccttUUsseerr) – The new user
│ │ │ │                    account.
│ │ │ │                Return type
│ │ │ │ -                  _s_t_r
│ │ │ │ +                  str
│ │ │ │          get_email_context(aaccttiivvaattiioonn__kkeeyy)_¶
│ │ │ │              Returns a dictionary of values to be used as template context when
│ │ │ │              generating the activation email.
│ │ │ │                Parameters
│ │ │ │ -                  aaccttiivvaattiioonn__kkeeyy (_ss_tt_rr) – The activation key for the new user
│ │ │ │ +                  aaccttiivvaattiioonn__kkeeyy (ssttrr) – The activation key for the new user
│ │ │ │                    account.
│ │ │ │                Return type
│ │ │ │ -                  _d_i_c_t
│ │ │ │ +                  dict
│ │ │ │          send_activation_email(uusseerr)_¶
│ │ │ │              Given an inactive user account, generates and sends the activation
│ │ │ │              email for that account.
│ │ │ │                Parameters
│ │ │ │ -                  uusseerr (_dd_jj_aa_nn_gg_oo_.._cc_oo_nn_tt_rr_ii_bb_.._aa_uu_tt_hh_.._mm_oo_dd_ee_ll_ss_.._AA_bb_ss_tt_rr_aa_cc_tt_UU_ss_ee_rr) – The new user
│ │ │ │ +                  uusseerr (ddjjaannggoo..ccoonnttrriibb..aauutthh..mmooddeellss..AAbbssttrraaccttUUsseerr) – The new user
│ │ │ │                    account.
│ │ │ │                Return type
│ │ │ │                    None
│ │ │ │          email_body_template_¶
│ │ │ │              A string specifying the template to use for the body of the
│ │ │ │              activation email. Default is“django_registration/
│ │ │ │              activation_email_body.txt”.
│ │ │ │ @@ -127,63 +127,63 @@
│ │ │ │          “invalid_key”
│ │ │ │              Generic indicator that the activation key was invalid.
│ │ │ │        Important customization points unique to this class are:
│ │ │ │          get_user(uusseerrnnaammee)_¶
│ │ │ │              Given a username (determined by the activation key), looks up and
│ │ │ │              returns the corresponding instance of the user model. If no such
│ │ │ │              account exists, raises _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r as described above. In the
│ │ │ │ -            base implementation, checks the _i_s___a_c_t_i_v_e field to avoid re-
│ │ │ │ +            base implementation, checks the is_active field to avoid re-
│ │ │ │              activating already-active accounts, and raises _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r with
│ │ │ │              codealready_activatedto indicate this case.
│ │ │ │                Parameters
│ │ │ │ -                  uusseerrnnaammee (_ss_tt_rr) – The username of the new user account.
│ │ │ │ +                  uusseerrnnaammee (ssttrr) – The username of the new user account.
│ │ │ │                Return type
│ │ │ │ -                  _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_u_t_h_._m_o_d_e_l_s_._A_b_s_t_r_a_c_t_U_s_e_r
│ │ │ │ +                  django.contrib.auth.models.AbstractUser
│ │ │ │                Raises
│ │ │ │                    _dd_jj_aa_nn_gg_oo____rr_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._AA_cc_tt_ii_vv_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if no
│ │ │ │                    matching inactive user account exists.
│ │ │ │          validate_key(aaccttiivvaattiioonn__kkeeyy)_¶
│ │ │ │              Given the activation key, verifies that it carries a valid
│ │ │ │              signature and a timestamp no older than the number of days
│ │ │ │              specified in the settingACCOUNT_ACTIVATION_DAYS, and returns the
│ │ │ │              username from the activation key. Raises _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r, as
│ │ │ │              described above, if the activation key has an invalid signature or
│ │ │ │              if the timestamp is too old.
│ │ │ │                Parameters
│ │ │ │ -                  aaccttiivvaattiioonn__kkeeyy (_ss_tt_rr) – The activation key for the new user
│ │ │ │ +                  aaccttiivvaattiioonn__kkeeyy (ssttrr) – The activation key for the new user
│ │ │ │                    account.
│ │ │ │                Return type
│ │ │ │ -                  _s_t_r
│ │ │ │ +                  str
│ │ │ │                Raises
│ │ │ │                    _dd_jj_aa_nn_gg_oo____rr_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._AA_cc_tt_ii_vv_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if the
│ │ │ │                    activation key has an invalid signature or is expired.
│ │ │ │        Note
│ │ │ │        UURRLL ppaatttteerrnnss ffoorr aaccttiivvaattiioonn
│ │ │ │        Although the actual value used in the activation key is the new user
│ │ │ │        account’s username, the URL pattern for ActivationView does not need to
│ │ │ │        match all possible legal characters in a username. The activation key
│ │ │ │        that will be sent to the user (and thus matched in the URL) is produced
│ │ │ │ -      by _d_j_a_n_g_o_._c_o_r_e_._s_i_g_n_i_n_g_._d_u_m_p_s_(_), which base64-encodes its output. Thus,
│ │ │ │ +      by django.core.signing.dumps(), which base64-encodes its output. Thus,
│ │ │ │        the only characters this pattern needs to match are those from _t_h_e_ _U_R_L_-
│ │ │ │        _s_a_f_e_ _b_a_s_e_6_4_ _a_l_p_h_a_b_e_t, plus the colon (”:”) which is used as a separator.
│ │ │ │        The default URL pattern for the activation view
│ │ │ │        indjango_registration.backends.activation.urlshandles this for you.
│ │ │ │  ********** HHooww iitt wwoorrkkss_?¶ **********
│ │ │ │  When a user signs up, the activation workflow creates a new user instance to
│ │ │ │ -represent the account, and sets theis_activefield to _F_a_l_s_e. It then sends an
│ │ │ │ +represent the account, and sets theis_activefield to False. It then sends an
│ │ │ │  email to the address provided during signup, containing a link to activate the
│ │ │ │  account. When the user clicks the link, the activation view setsis_activeto
│ │ │ │ -_T_r_u_e, after which the user can log in.
│ │ │ │ +True, after which the user can log in.
│ │ │ │  The activation key is the username of the new account, signed using _D_j_a_n_g_o_’_s
│ │ │ │ -_c_r_y_p_t_o_g_r_a_p_h_i_c_ _s_i_g_n_i_n_g_ _t_o_o_l_s (specifically, _d_u_m_p_s_(_) is used, to produce a
│ │ │ │ +_c_r_y_p_t_o_g_r_a_p_h_i_c_ _s_i_g_n_i_n_g_ _t_o_o_l_s (specifically, dumps() is used, to produce a
│ │ │ │  guaranteed-URL-safe value). The activation process includes verification of the
│ │ │ │  signature prior to activation, as well as verifying that the user is activating
│ │ │ │  within the permitted window (as specified in the setting
│ │ │ │  _A_C_C_O_U_N_T___A_C_T_I_V_A_T_I_O_N___D_A_Y_S, mentioned above), through use of Django’s
│ │ │ │ -_T_i_m_e_s_t_a_m_p_S_i_g_n_e_r.
│ │ │ │ +TimestampSigner.
│ │ │ │  ********** SSeeccuurriittyy ccoonnssiiddeerraattiioonnss_?¶ **********
│ │ │ │  The activation key emailed to the user in the activation workflow is a value
│ │ │ │  obtained by using Django’s cryptographic signing tools. The activation key is
│ │ │ │  of the form:
│ │ │ │  encoded_username:timestamp:signature
│ │ │ │  whereencoded_usernameis the username of the new account,timestampis the
│ │ │ │  timestamp of the time the user registered, andsignatureis an HMAC of the
│ │ ├── ./usr/share/doc/python-django-registration-doc/html/custom-user.html
│ │ │ @@ -139,83 +139,83 @@
│ │ │  your user model.

│ │ │  

│ │ │  
The two-step activation workflow

│ │ │  
The two-step activation workflow requires
│ │ │  that the following be true of your user model:

│ │ │  
    
│ │ │  
  • Your user model must set the attribute
│ │ │ -USERNAME_FIELD to
│ │ │ +USERNAME_FIELD to
│ │ │  indicate the field used as the username.
    • 
│ │ │  
  • Your user model must have a field (of some textual type, ideally
│ │ │ -EmailField) for storing an email address,
│ │ │ +EmailField) for storing an email address,
│ │ │  and it must define the method
│ │ │ -get_email_field_name()
│ │ │ +get_email_field_name()
│ │ │  to indicate the name of the email field.
    • 
│ │ │  
  • The username and email fields must be distinct. If you wish to use
│ │ │  the email address as the username, you will need to write your own
│ │ │  completely custom registration form.
    • 
│ │ │  
  • Your user model must have a field named
│ │ │ -is_active, and that field
│ │ │ -must be a BooleanField indicating whether
│ │ │ +is_active, and that field
│ │ │ +must be a BooleanField indicating whether
│ │ │  the user’s account is active.
    • 
│ │ │  

│ │ │  
If your user model is a subclass of Django’s
│ │ │ -AbstractBaseUser, all of the
│ │ │ +AbstractBaseUser, all of the
│ │ │  above will be automatically handled for you.

│ │ │  
If your custom user model defines additional fields beyond the minimum
│ │ │  requirements, you’ll either need to ensure that all of those fields
│ │ │  are optional (i.e., can be NULL in your database, or provide a
│ │ │  suitable default value defined in the model), or specify the correct
│ │ │  list of fields to display in your
│ │ │  RegistrationForm subclass.

│ │ │  

│ │ │  

│ │ │  
The one-step workflow

│ │ │  
The one-step workflow places the following
│ │ │  requirements on your user model:

│ │ │  
    
│ │ │  
  • Your user model must set the attribute
│ │ │ -USERNAME_FIELD to
│ │ │ +USERNAME_FIELD to
│ │ │  indicate the field used as the username.
    • 
│ │ │  
  • It must define a textual field named password for storing the
│ │ │  user’s password.
    • 
│ │ │  

│ │ │  
Also note that the base
│ │ │  RegistrationForm includes and
│ │ │  requires an email field, so either provide that field on your model
│ │ │  and set the
│ │ │ -get_email_field_name()
│ │ │ +get_email_field_name()
│ │ │  attribute to indicate which field it is, or subclass
│ │ │  RegistrationForm and override to
│ │ │  remove the email field or make it optional.

│ │ │  
If your user model is a subclass of Django’s
│ │ │ -AbstractBaseUser, all of the
│ │ │ +AbstractBaseUser, all of the
│ │ │  above will be automatically handled for you.

│ │ │  
If your custom user model defines additional fields beyond the minimum
│ │ │  requirements, you’ll either need to ensure that all of those fields
│ │ │  are optional (i.e., can be NULL in your database, or provide a
│ │ │  suitable default value defined in the model), or specify the correct
│ │ │  list of fields to display in your
│ │ │  RegistrationForm subclass.

│ │ │  
Because the one-step workflow logs in the new account immediately
│ │ │  after creating it, you also must either use Django’s
│ │ │ -ModelBackend as an
│ │ │ +ModelBackend as an
│ │ │  authentication backend,
│ │ │  or use an authentication backend which accepts a combination of
│ │ │  USERNAME_FIELD and password as sufficient credentials to
│ │ │  authenticate a user.

│ │ │  

│ │ │
│ │ │
│ │ │

Writing your form subclass

│ │ │

The base RegistrationView contains │ │ │ code which compares the declared model of your registration form with │ │ │ the user model of your Django installation. If these are not the same │ │ │ model, the view will deliberately crash by raising an │ │ │ -ImproperlyConfigured exception, with an │ │ │ +ImproperlyConfigured exception, with an │ │ │ error message alerting you to the problem.

│ │ │

This will happen automatically if you attempt to use │ │ │ django-registration with a custom user model and also attempt to use │ │ │ the default, unmodified │ │ │ RegistrationForm. This is, again, │ │ │ a deliberate design feature of django-registration, and not a bug: │ │ │ django-registration has no way of knowing in advance if your user │ │ │ ├── html2text {} │ │ │ │ @@ -60,58 +60,58 @@ │ │ │ │ about the structure of your user model in order to work with it. If you intend │ │ │ │ to use one of django-registration’s built-in registration workflows, please │ │ │ │ carefully read the appropriate section to see what it expects from your user │ │ │ │ model. │ │ │ │ ******** TThhee ttwwoo--sstteepp aaccttiivvaattiioonn wwoorrkkffllooww_?¶ ******** │ │ │ │ _T_h_e_ _t_w_o_-_s_t_e_p_ _a_c_t_i_v_a_t_i_o_n_ _w_o_r_k_f_l_o_w requires that the following be true of your │ │ │ │ user model: │ │ │ │ - * Your user model must set the attribute _U_S_E_R_N_A_M_E___F_I_E_L_D to indicate the │ │ │ │ + * Your user model must set the attribute USERNAME_FIELD to indicate the │ │ │ │ field used as the username. │ │ │ │ * Your user model must have a field (of some textual type, ideally │ │ │ │ - _E_m_a_i_l_F_i_e_l_d) for storing an email address, and it must define the method │ │ │ │ - _g_e_t___e_m_a_i_l___f_i_e_l_d___n_a_m_e_(_) to indicate the name of the email field. │ │ │ │ + EmailField) for storing an email address, and it must define the method │ │ │ │ + get_email_field_name() to indicate the name of the email field. │ │ │ │ * The username and email fields must be distinct. If you wish to use the │ │ │ │ email address as the username, you will need to write your own completely │ │ │ │ custom registration form. │ │ │ │ - * Your user model must have a field named _i_s___a_c_t_i_v_e, and that field must be │ │ │ │ - a _B_o_o_l_e_a_n_F_i_e_l_d indicating whether the user’s account is active. │ │ │ │ -If your user model is a subclass of Django’s _A_b_s_t_r_a_c_t_B_a_s_e_U_s_e_r, all of the above │ │ │ │ + * Your user model must have a field named is_active, and that field must be │ │ │ │ + a BooleanField indicating whether the user’s account is active. │ │ │ │ +If your user model is a subclass of Django’s AbstractBaseUser, all of the above │ │ │ │ will be automatically handled for you. │ │ │ │ If your custom user model defines additional fields beyond the minimum │ │ │ │ requirements, you’ll either need to ensure that all of those fields are │ │ │ │ optional (i.e., can beNULLin your database, or provide a suitable default value │ │ │ │ defined in the model), or specify the correct list of fields to display in your │ │ │ │ _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m subclass. │ │ │ │ ******** TThhee oonnee--sstteepp wwoorrkkffllooww_?¶ ******** │ │ │ │ _T_h_e_ _o_n_e_-_s_t_e_p_ _w_o_r_k_f_l_o_w places the following requirements on your user model: │ │ │ │ - * Your user model must set the attribute _U_S_E_R_N_A_M_E___F_I_E_L_D to indicate the │ │ │ │ + * Your user model must set the attribute USERNAME_FIELD to indicate the │ │ │ │ field used as the username. │ │ │ │ * It must define a textual field namedpasswordfor storing the user’s │ │ │ │ password. │ │ │ │ Also note that the base _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m includes and requires an email field, │ │ │ │ -so either provide that field on your model and set the _g_e_t___e_m_a_i_l___f_i_e_l_d___n_a_m_e_(_) │ │ │ │ +so either provide that field on your model and set the get_email_field_name() │ │ │ │ attribute to indicate which field it is, or subclass _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m and │ │ │ │ override to remove theemailfield or make it optional. │ │ │ │ -If your user model is a subclass of Django’s _A_b_s_t_r_a_c_t_B_a_s_e_U_s_e_r, all of the above │ │ │ │ +If your user model is a subclass of Django’s AbstractBaseUser, all of the above │ │ │ │ will be automatically handled for you. │ │ │ │ If your custom user model defines additional fields beyond the minimum │ │ │ │ requirements, you’ll either need to ensure that all of those fields are │ │ │ │ optional (i.e., can beNULLin your database, or provide a suitable default value │ │ │ │ defined in the model), or specify the correct list of fields to display in your │ │ │ │ _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m subclass. │ │ │ │ Because the one-step workflow logs in the new account immediately after │ │ │ │ -creating it, you also must either use Django’s _M_o_d_e_l_B_a_c_k_e_n_d as an │ │ │ │ +creating it, you also must either use Django’s ModelBackend as an │ │ │ │ _a_u_t_h_e_n_t_i_c_a_t_i_o_n_ _b_a_c_k_e_n_d, or use an authentication backend which accepts a │ │ │ │ combination ofUSERNAME_FIELDandpasswordas sufficient credentials to │ │ │ │ authenticate a user. │ │ │ │ ********** WWrriittiinngg yyoouurr ffoorrmm ssuubbccllaassss_?¶ ********** │ │ │ │ The base _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w contains code which compares the declared model of │ │ │ │ your registration form with the user model of your Django installation. If │ │ │ │ these are not the same model, the view will deliberately crash by raising an │ │ │ │ -_I_m_p_r_o_p_e_r_l_y_C_o_n_f_i_g_u_r_e_d exception, with an error message alerting you to the │ │ │ │ +ImproperlyConfigured exception, with an error message alerting you to the │ │ │ │ problem. │ │ │ │ This will happen automatically if you attempt to use django-registration with a │ │ │ │ custom user model and also attempt to use the default, unmodified │ │ │ │ RegistrationForm. This is, again, a deliberate design feature of django- │ │ │ │ registration, and not a bug: django-registration has no way of knowing in │ │ │ │ advance if your user model is compatible with the assumptions made by the │ │ │ │ built-in registration workflows (see above), so it requires you to take the │ │ ├── ./usr/share/doc/python-django-registration-doc/html/exceptions.html │ │ │ @@ -101,18 +101,18 @@ │ │ │ exception directly; it serves solely to provide a distinguishing │ │ │ parent class for other errors. Arguments passed when the exception │ │ │ is raised will be stored and exposed as attributes of the same │ │ │ names on the exception object:

│ │ │
│ │ │
Parameters
│ │ │
    │ │ │ -

  • message (str) – A human-readable error message.

    • │ │ │ -

  • code (str) – A short but unique identifier used by subclasses │ │ │ +

  • message (str) – A human-readable error message.

    • │ │ │ +

  • code (str) – A short but unique identifier used by subclasses │ │ │ to distinguish different error conditions.

    • │ │ │ -

  • params (dict) – Arbitrary key-value data to associate with the error.

    • │ │ │ +

  • params (dict) – Arbitrary key-value data to associate with the error.

    • │ │ │
│ │ │
│ │ │
│ │ │ │ │ │ │ │ │
│ │ │
│ │ │ ├── html2text {} │ │ │ │ @@ -32,18 +32,18 @@ │ │ │ │ ppaarraammss)_¶ │ │ │ │ Base exception class for all exceptions raised in django-registration. No │ │ │ │ code in django-registration will raise this exception directly; it serves │ │ │ │ solely to provide a distinguishing parent class for other errors. │ │ │ │ Arguments passed when the exception is raised will be stored and exposed │ │ │ │ as attributes of the same names on the exception object: │ │ │ │ Parameters │ │ │ │ - * mmeessssaaggee (_ss_tt_rr) – A human-readable error message. │ │ │ │ - * ccooddee (_ss_tt_rr) – A short but unique identifier used by subclasses │ │ │ │ + * mmeessssaaggee (ssttrr) – A human-readable error message. │ │ │ │ + * ccooddee (ssttrr) – A short but unique identifier used by subclasses │ │ │ │ to distinguish different error conditions. │ │ │ │ - * ppaarraammss (_dd_ii_cc_tt) – Arbitrary key-value data to associate with │ │ │ │ + * ppaarraammss (ddiicctt) – Arbitrary key-value data to associate with │ │ │ │ the error. │ │ │ │ eexxcceeppttiioonn django_registration.exceptions.ActivationError(mmeessssaaggee, ccooddee, │ │ │ │ ppaarraammss)_¶ │ │ │ │ Exception class to indicate errors during account activation. Subclass of │ │ │ │ _R_e_g_i_s_t_r_a_t_i_o_n_E_r_r_o_r and inherits its attributes. │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ =============================================================================== │ │ ├── ./usr/share/doc/python-django-registration-doc/html/forms.html │ │ │ @@ -96,15 +96,15 @@ │ │ │ implementing common constraints for user registration. These forms │ │ │ were designed with django-registration’s built-in registration │ │ │ workflows in mind, but may also be useful in other situations.

│ │ │
│ │ │
│ │ │ class django_registration.forms.RegistrationForm
│ │ │

A form for registering an account. This is a subclass of Django’s │ │ │ -built-in UserCreationForm, and │ │ │ +built-in UserCreationForm, and │ │ │ has the following fields, all of which are required:

│ │ │
│ │ │
username

The username to use for the new account.

│ │ │
│ │ │
email

The email address to use for the new account.

│ │ │
│ │ │
password1

The password to use for the new account.

│ │ │ @@ -113,20 +113,20 @@ │ │ │ typos.

│ │ │
│ │ │
│ │ │
│ │ │

Note

│ │ │

Validation of usernames

│ │ │

Django supplies a default regex-based validator for usernames in │ │ │ -its base AbstractBaseUser │ │ │ +its base AbstractBaseUser │ │ │ implementation, allowing any word character along with the │ │ │ following set of additional characters: ., @, +, and │ │ │ -.

│ │ │

Because it’s a subclass of Django’s │ │ │ -UserCreationForm, │ │ │ +UserCreationForm, │ │ │ RegistrationForm will inherit the base validation │ │ │ defined by Django. It also applies some custom validators to the │ │ │ username: │ │ │ ReservedNameValidator, │ │ │ and │ │ │ validate_confusables().

│ │ │
│ │ │ ├── html2text {} │ │ │ │ @@ -28,30 +28,30 @@ │ │ │ │ ************ BBaassee ffoorrmm ccllaasssseess_?¶ ************ │ │ │ │ Several form classes are provided with django-registration, covering common │ │ │ │ cases for gathering account information and implementing common constraints for │ │ │ │ user registration. These forms were designed with django-registration’s built- │ │ │ │ in registration workflows in mind, but may also be useful in other situations. │ │ │ │ ccllaassss django_registration.forms.RegistrationForm_¶ │ │ │ │ A form for registering an account. This is a subclass of Django’s built- │ │ │ │ - in _U_s_e_r_C_r_e_a_t_i_o_n_F_o_r_m, and has the following fields, all of which are │ │ │ │ + in UserCreationForm, and has the following fields, all of which are │ │ │ │ required: │ │ │ │ username │ │ │ │ The username to use for the new account. │ │ │ │ email │ │ │ │ The email address to use for the new account. │ │ │ │ password1 │ │ │ │ The password to use for the new account. │ │ │ │ password2 │ │ │ │ The password to use for the new account, repeated to catch typos. │ │ │ │ Note │ │ │ │ VVaalliiddaattiioonn ooff uusseerrnnaammeess │ │ │ │ Django supplies a default regex-based validator for usernames in its base │ │ │ │ - _A_b_s_t_r_a_c_t_B_a_s_e_U_s_e_r implementation, allowing any word character along with │ │ │ │ + AbstractBaseUser implementation, allowing any word character along with │ │ │ │ the following set of additional characters:.,@,+, and-. │ │ │ │ - Because it’s a subclass of Django’s _U_s_e_r_C_r_e_a_t_i_o_n_F_o_r_m, _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m │ │ │ │ + Because it’s a subclass of Django’s UserCreationForm, _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m │ │ │ │ will inherit the base validation defined by Django. It also applies some │ │ │ │ custom validators to the username: _R_e_s_e_r_v_e_d_N_a_m_e_V_a_l_i_d_a_t_o_r, and │ │ │ │ _v_a_l_i_d_a_t_e___c_o_n_f_u_s_a_b_l_e_s_(_). │ │ │ │ Note │ │ │ │ VVaalliiddaattiioonn ooff eemmaaiill aaddddrreesssseess │ │ │ │ django-registration applies two additional validators – │ │ │ │ _H_T_M_L_5_E_m_a_i_l_V_a_l_i_d_a_t_o_r and _v_a_l_i_d_a_t_e___c_o_n_f_u_s_a_b_l_e_s___e_m_a_i_l_(_) – to the email │ │ ├── ./usr/share/doc/python-django-registration-doc/html/quickstart.html │ │ │ @@ -212,15 +212,15 @@ │ │ │
│ │ │

Required templates

│ │ │

You will also need to create several templates required by │ │ │ django-registration, and possibly additional templates required by │ │ │ views in django.contrib.auth. The templates required by │ │ │ django-registration are as follows; note that, with the exception of │ │ │ the templates used for account activation emails, all of these are │ │ │ -rendered using a RequestContext and so will │ │ │ +rendered using a RequestContext and so will │ │ │ also receive any additional variables provided by context processors.

│ │ │
│ │ │

django_registration/registration_form.html

│ │ │

Used to show the form users will fill out to register. By default, has │ │ │ the following context:

│ │ │
│ │ │
form

The registration form. This will likely be a subclass of │ │ │ @@ -242,15 +242,15 @@ │ │ │

Used when registration of new user accounts is disabled. This template │ │ │ has no context variables of its own.

│ │ │
│ │ │
│ │ │

django_registration/activation_failed.html

│ │ │

Used if account activation fails. Has the following context:

│ │ │
│ │ │ -
activation_error

A dict containing the information supplied to the │ │ │ +

activation_error

A dict containing the information supplied to the │ │ │ ActivationError which │ │ │ occurred during activation. See the documentation for that │ │ │ exception for a description of the keys, and the documentation for │ │ │ ActivationView │ │ │ for the specific values used in different failure situations.

│ │ │
│ │ │
│ │ │ @@ -269,25 +269,25 @@ │ │ │ being used. This template has the following context:

│ │ │
│ │ │
activation_key

The activation key for the new account, as a string.

│ │ │
│ │ │
expiration_days

The number of days remaining during which the account may be │ │ │ activated, as an integer.

│ │ │
│ │ │ -
request

The HttpRequest object representing the │ │ │ +

request

The HttpRequest object representing the │ │ │ request in which the user registered.

│ │ │
│ │ │
scheme

The protocol scheme used during registration, as a string; will be │ │ │ either ‘http’ or ‘https’.

│ │ │
│ │ │
site

An object representing the site on which the user registered; │ │ │ depending on whether django.contrib.sites is installed, this may │ │ │ -be an instance of either django.contrib.sites.models.Site │ │ │ +be an instance of either django.contrib.sites.models.Site │ │ │ (if the sites application is installed) or │ │ │ -django.contrib.sites.requests.RequestSite (if │ │ │ +django.contrib.sites.requests.RequestSite (if │ │ │ not). Consult the documentation for the Django sites framework │ │ │ for details regarding these objects’ interfaces.

│ │ │
│ │ │
user

The newly-created user object.

│ │ │
│ │ │
│ │ │
│ │ │ @@ -298,25 +298,25 @@ │ │ │ following context:

│ │ │
│ │ │
activation_key

The activation key for the new account, as a string.

│ │ │
│ │ │
expiration_days

The number of days remaining during which the account may be │ │ │ activated, as an integer.

│ │ │
│ │ │ -
request

The HttpRequest object representing the │ │ │ +

request

The HttpRequest object representing the │ │ │ request in which the user registered.

│ │ │
│ │ │
scheme

The protocol scheme used during registration, as a string; will be │ │ │ either ‘http’ or ‘https’.

│ │ │
│ │ │
site

An object representing the site on which the user registered; │ │ │ depending on whether django.contrib.sites is installed, this may │ │ │ -be an instance of either django.contrib.sites.models.Site │ │ │ +be an instance of either django.contrib.sites.models.Site │ │ │ (if the sites application is installed) or │ │ │ -django.contrib.sites.requests.RequestSite (if │ │ │ +django.contrib.sites.requests.RequestSite (if │ │ │ not). Consult the documentation for the Django sites framework │ │ │ for details regarding these objects.

│ │ │
│ │ │
user

The newly-created user object.

│ │ │
│ │ │
│ │ │

Note that the templates used to generate the account activation email │ │ │ @@ -333,15 +333,15 @@ │ │ │

│ │ │
│ │ │
│ │ │

Configuring the one-step workflow

│ │ │

Also included is a one-step registration workflow, where a user signs up and their account is │ │ │ immediately active and logged in.

│ │ │

You will need to configure URLs to use the one-step workflow; the │ │ │ -easiest way is to include() the URLconf │ │ │ +easiest way is to include() the URLconf │ │ │ django_registration.backends.one_step.urls somewhere in your URL │ │ │ configuration. For example, to place the URLs under the prefix │ │ │ /accounts/ in your URL structure:

│ │ │ 
from django.urls import include, path
│ │ │  
│ │ │  urlpatterns = [
│ │ │      # Other URL patterns ...
│ │ │ ├── html2text {}
│ │ │ │ @@ -111,15 +111,15 @@
│ │ │ │      * django_registration_disallowedis a message indicating registration is not
│ │ │ │        currently permitted.
│ │ │ │  ******** RReeqquuiirreedd tteemmppllaatteess_?¶ ********
│ │ │ │  You will also need to create several templates required by django-registration,
│ │ │ │  and possibly additional templates required by views indjango.contrib.auth. The
│ │ │ │  templates required by django-registration are as follows; note that, with the
│ │ │ │  exception of the templates used for account activation emails, all of these are
│ │ │ │ -rendered using a _R_e_q_u_e_s_t_C_o_n_t_e_x_t and so will also receive any additional
│ │ │ │ +rendered using a RequestContext and so will also receive any additional
│ │ │ │  variables provided by _c_o_n_t_e_x_t_ _p_r_o_c_e_s_s_o_r_s.
│ │ │ │  ****** ddjjaannggoo__rreeggiissttrraattiioonn//rreeggiissttrraattiioonn__ffoorrmm..hhttmmll_?¶ ******
│ │ │ │  Used to show the form users will fill out to register. By default, has the
│ │ │ │  following context:
│ │ │ │    form
│ │ │ │        The registration form. This will likely be a subclass of
│ │ │ │        _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m; consult _D_j_a_n_g_o_’_s_ _f_o_r_m_s_ _d_o_c_u_m_e_n_t_a_t_i_o_n for information on
│ │ │ │ @@ -130,15 +130,15 @@
│ │ │ │  containing account-activation information has been sent.
│ │ │ │  ****** ddjjaannggoo__rreeggiissttrraattiioonn//rreeggiissttrraattiioonn__cclloosseedd..hhttmmll_?¶ ******
│ │ │ │  Used when registration of new user accounts is disabled. This template has no
│ │ │ │  context variables of its own.
│ │ │ │  ****** ddjjaannggoo__rreeggiissttrraattiioonn//aaccttiivvaattiioonn__ffaaiilleedd..hhttmmll_?¶ ******
│ │ │ │  Used if account activation fails. Has the following context:
│ │ │ │    activation_error
│ │ │ │ -      A _d_i_c_t containing the information supplied to the _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r which
│ │ │ │ +      A dict containing the information supplied to the _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r which
│ │ │ │        occurred during activation. See the documentation for that exception for
│ │ │ │        a description of the keys, and the documentation for _A_c_t_i_v_a_t_i_o_n_V_i_e_w for
│ │ │ │        the specific values used in different failure situations.
│ │ │ │  ****** ddjjaannggoo__rreeggiissttrraattiioonn//aaccttiivvaattiioonn__ccoommpplleettee..hhttmmll_?¶ ******
│ │ │ │  Used after successful account activation. This template has no context
│ │ │ │  variables of its own, and should inform the user that their account is now
│ │ │ │  active.
│ │ │ │ @@ -149,48 +149,48 @@
│ │ │ │  has the following context:
│ │ │ │    activation_key
│ │ │ │        The activation key for the new account, as a string.
│ │ │ │    expiration_days
│ │ │ │        The number of days remaining during which the account may be activated,
│ │ │ │        as an integer.
│ │ │ │    request
│ │ │ │ -      The _H_t_t_p_R_e_q_u_e_s_t object representing the request in which the user
│ │ │ │ +      The HttpRequest object representing the request in which the user
│ │ │ │        registered.
│ │ │ │    scheme
│ │ │ │        The protocol scheme used during registration, as a string; will be
│ │ │ │        either‘http’or‘https’.
│ │ │ │    site
│ │ │ │        An object representing the site on which the user registered; depending
│ │ │ │        on whetherdjango.contrib.sitesis installed, this may be an instance of
│ │ │ │ -      either _d_j_a_n_g_o_._c_o_n_t_r_i_b_._s_i_t_e_s_._m_o_d_e_l_s_._S_i_t_e (if the sites application is
│ │ │ │ -      installed) or _d_j_a_n_g_o_._c_o_n_t_r_i_b_._s_i_t_e_s_._r_e_q_u_e_s_t_s_._R_e_q_u_e_s_t_S_i_t_e (if not). Consult
│ │ │ │ +      either django.contrib.sites.models.Site (if the sites application is
│ │ │ │ +      installed) or django.contrib.sites.requests.RequestSite (if not). Consult
│ │ │ │        _t_h_e_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _f_o_r_ _t_h_e_ _D_j_a_n_g_o_ _s_i_t_e_s_ _f_r_a_m_e_w_o_r_k for details regarding
│ │ │ │        these objects’ interfaces.
│ │ │ │    user
│ │ │ │        The newly-created user object.
│ │ │ │  ****** ddjjaannggoo__rreeggiissttrraattiioonn//aaccttiivvaattiioonn__eemmaaiill__bbooddyy..ttxxtt_?¶ ******
│ │ │ │  Used to generate the body of the activation email. Should display a link the
│ │ │ │  user can click to activate the account. This template has the following
│ │ │ │  context:
│ │ │ │    activation_key
│ │ │ │        The activation key for the new account, as a string.
│ │ │ │    expiration_days
│ │ │ │        The number of days remaining during which the account may be activated,
│ │ │ │        as an integer.
│ │ │ │    request
│ │ │ │ -      The _H_t_t_p_R_e_q_u_e_s_t object representing the request in which the user
│ │ │ │ +      The HttpRequest object representing the request in which the user
│ │ │ │        registered.
│ │ │ │    scheme
│ │ │ │        The protocol scheme used during registration, as a string; will be
│ │ │ │        either‘http’or‘https’.
│ │ │ │    site
│ │ │ │        An object representing the site on which the user registered; depending
│ │ │ │        on whetherdjango.contrib.sitesis installed, this may be an instance of
│ │ │ │ -      either _d_j_a_n_g_o_._c_o_n_t_r_i_b_._s_i_t_e_s_._m_o_d_e_l_s_._S_i_t_e (if the sites application is
│ │ │ │ -      installed) or _d_j_a_n_g_o_._c_o_n_t_r_i_b_._s_i_t_e_s_._r_e_q_u_e_s_t_s_._R_e_q_u_e_s_t_S_i_t_e (if not). Consult
│ │ │ │ +      either django.contrib.sites.models.Site (if the sites application is
│ │ │ │ +      installed) or django.contrib.sites.requests.RequestSite (if not). Consult
│ │ │ │        _t_h_e_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _f_o_r_ _t_h_e_ _D_j_a_n_g_o_ _s_i_t_e_s_ _f_r_a_m_e_w_o_r_k for details regarding
│ │ │ │        these objects.
│ │ │ │    user
│ │ │ │        The newly-created user object.
│ │ │ │  Note that the templates used to generate the account activation email use the
│ │ │ │  extension.txt, not.html. Due to widespread antipathy toward and
│ │ │ │  interoperability problems with HTML email, django-registration produces plain-
│ │ │ │ @@ -199,15 +199,15 @@
│ │ │ │  the example URL configuration above), you will also need to create the
│ │ │ │  templates required by those views. Consult _t_h_e_ _d_o_c_u_m_e_n_t_a_t_i_o_n_ _f_o_r_ _D_j_a_n_g_o_’_s
│ │ │ │  _a_u_t_h_e_n_t_i_c_a_t_i_o_n_ _s_y_s_t_e_m for details regarding these templates.
│ │ │ │  ********** CCoonnffiigguurriinngg tthhee oonnee--sstteepp wwoorrkkffllooww_?¶ **********
│ │ │ │  Also included is a _o_n_e_-_s_t_e_p_ _r_e_g_i_s_t_r_a_t_i_o_n_ _w_o_r_k_f_l_o_w, where a user signs up and
│ │ │ │  their account is immediately active and logged in.
│ │ │ │  You will need to configure URLs to use the one-step workflow; the easiest way
│ │ │ │ -is to _i_n_c_l_u_d_e_(_) the URLconfdjango_registration.backends.one_step.urlssomewhere
│ │ │ │ +is to include() the URLconfdjango_registration.backends.one_step.urlssomewhere
│ │ │ │  in your URL configuration. For example, to place the URLs under the prefix/
│ │ │ │  accounts/in your URL structure:
│ │ │ │  from django.urls import include, path
│ │ │ │  
│ │ │ │  urlpatterns = [
│ │ │ │      # Other URL patterns ...
│ │ │ │      path('accounts/', include('django_registration.backends.one_step.urls')),
│ │ ├── ./usr/share/doc/python-django-registration-doc/html/security.html
│ │ │ @@ -211,15 +211,15 @@
│ │ │  django-registration alone can protect your users. Other features of
│ │ │  Django itself, or of other third-party applications, can provide
│ │ │  significant increases in protection.

│ │ │  
In particular, it is recommended that you:

│ │ │  
    
│ │ │  
  • Prevent the use of common passwords. You can catch some common
│ │ │  passwords by enabling Django’s
│ │ │ -CommonPasswordValidator,
│ │ │ +CommonPasswordValidator,
│ │ │  which uses a list of twenty thousand common passwords. A more
│ │ │  comprehensive option is the password validator and other utilities
│ │ │  from pwned-passwords-django, which
│ │ │  checks against a database containing (as of mid-2018) over half a
│ │ │  billion passwords found in data breaches.
    • 
│ │ │  
  • Use two-factor authentication via authenticator applications or
│ │ │  hardware security keys (not SMS). The package django-two-factor
│ │ │ ├── html2text {}
│ │ │ │ @@ -115,15 +115,15 @@
│ │ │ │  ********** AAddddiittiioonnaall sstteeppss ttoo sseeccuurree uusseerr aaccccoouunnttss_?¶ **********
│ │ │ │  The scope of django-registration is solely the implementation of user-signup
│ │ │ │  workflows, which limits the ways in which django-registration alone can protect
│ │ │ │  your users. Other features of Django itself, or of other third-party
│ │ │ │  applications, can provide significant increases in protection.
│ │ │ │  In particular, it is recommended that you:
│ │ │ │      * Prevent the use of common passwords. You can catch some common passwords
│ │ │ │ -      by enabling Django’s _C_o_m_m_o_n_P_a_s_s_w_o_r_d_V_a_l_i_d_a_t_o_r, which uses a list of twenty
│ │ │ │ +      by enabling Django’s CommonPasswordValidator, which uses a list of twenty
│ │ │ │        thousand common passwords. A more comprehensive option is the password
│ │ │ │        validator and other utilities from _p_w_n_e_d_-_p_a_s_s_w_o_r_d_s_-_d_j_a_n_g_o, which checks
│ │ │ │        against a database containing (as of mid-2018) over half a billion
│ │ │ │        passwords found in data breaches.
│ │ │ │      * Use two-factor authentication via authenticator applications or hardware
│ │ │ │        security keys (nnoott SMS). The package _d_j_a_n_g_o_-_t_w_o_-_f_a_c_t_o_r provides
│ │ │ │        integration for two-factor authentication into Django’s auth framework.
│ │ ├── ./usr/share/doc/python-django-registration-doc/html/settings.html
│ │ │ @@ -95,26 +95,26 @@
│ │ │  require changes to your Django settings (as registration workflows are
│ │ │  selected by including the appropriate URL patterns in your root
│ │ │  URLconf), the built-in workflows of django-registration make use
│ │ │  of several custom settings.
    
│ │ │  
    
│ │ │  
    
│ │ │  django.conf.settings.ACCOUNT_ACTIVATION_DAYS
    
│ │ │ -
    An int indicating how long (in days) after signup an
│ │ │ +
    An int indicating how long (in days) after signup an
│ │ │  account has in which to activate.
    
│ │ │  
    Used by:
    
│ │ │  
│ │ │  
    
│ │ │  
│ │ │  
    
│ │ │  
    
│ │ │  django.conf.settings.REGISTRATION_OPEN
    
│ │ │ -
    A bool indicating whether registration of new accounts is
│ │ │ +
    A bool indicating whether registration of new accounts is
│ │ │  currently permitted.
    
│ │ │  
    A default of True is assumed when this setting is not supplied,
│ │ │  so specifying it is optional unless you want to temporarily close
│ │ │  registration (in which case, set it to False).
    
│ │ │  
    Used by:
    
│ │ │  
    
│ │ │  
│ │ │  
    
│ │ │  
    
│ │ │  django.conf.settings.REGISTRATION_SALT
    
│ │ │ -
    A str used as an additional “salt” in the process of
│ │ │ +
    A str used as an additional “salt” in the process of
│ │ │  generating signed activation keys.
    
│ │ │  
    This setting is optional, and a default of “registration” will
│ │ │  be used if not specified. The value of this setting does not need
│ │ │  to be kept secret; see the note about this salt value and
│ │ │  security for details.
    
│ │ │  
    Used by:
    
│ │ │  
      
│ │ │ ├── html2text {}
│ │ │ │ @@ -27,33 +27,33 @@
│ │ │ │  ===============================================================================
│ │ │ │  ************ CCuussttoomm sseettttiinnggss_?¶ ************
│ │ │ │  Although the choice of registration workflow does not necessarily require
│ │ │ │  changes to your Django settings (as registration workflows are selected by
│ │ │ │  including the appropriate URL patterns in your root URLconf), the built-in
│ │ │ │  workflows of django-registration make use of several custom settings.
│ │ │ │    django.conf.settings.ACCOUNT_ACTIVATION_DAYS_¶
│ │ │ │ -      An _i_n_t indicating how long (in days) after signup an account has in which
│ │ │ │ +      An int indicating how long (in days) after signup an account has in which
│ │ │ │        to activate.
│ │ │ │        Used by:
│ │ │ │            * _T_h_e_ _t_w_o_-_s_t_e_p_ _a_c_t_i_v_a_t_i_o_n_ _w_o_r_k_f_l_o_w
│ │ │ │    django.conf.settings.REGISTRATION_OPEN_¶
│ │ │ │ -      A _b_o_o_l indicating whether registration of new accounts is currently
│ │ │ │ +      A bool indicating whether registration of new accounts is currently
│ │ │ │        permitted.
│ │ │ │        A default ofTrueis assumed when this setting is not supplied, so
│ │ │ │        specifying it is optional unless you want to temporarily close
│ │ │ │        registration (in which case, set it toFalse).
│ │ │ │        Used by:
│ │ │ │            * _T_h_e_ _t_w_o_-_s_t_e_p_ _a_c_t_i_v_a_t_i_o_n_ _w_o_r_k_f_l_o_w
│ │ │ │            * _T_h_e_ _o_n_e_-_s_t_e_p_ _w_o_r_k_f_l_o_w
│ │ │ │        Third-party workflows wishing to use an alternate method of determining
│ │ │ │        whether registration is allowed should subclass
│ │ │ │        _d_j_a_n_g_o___r_e_g_i_s_t_r_a_t_i_o_n_._v_i_e_w_s_._R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w (or a subclass of it from an
│ │ │ │        existing workflow) and override _r_e_g_i_s_t_r_a_t_i_o_n___a_l_l_o_w_e_d_(_).
│ │ │ │    django.conf.settings.REGISTRATION_SALT_¶
│ │ │ │ -      A _s_t_r used as an additional “salt” in the process of generating signed
│ │ │ │ +      A str used as an additional “salt” in the process of generating signed
│ │ │ │        activation keys.
│ │ │ │        This setting is optional, and a default of“registration”will be used if
│ │ │ │        not specified. The value of this setting does not need to be kept secret;
│ │ │ │        see _t_h_e_ _n_o_t_e_ _a_b_o_u_t_ _t_h_i_s_ _s_a_l_t_ _v_a_l_u_e_ _a_n_d_ _s_e_c_u_r_i_t_y for details.
│ │ │ │        Used by:
│ │ │ │            * _T_h_e_ _t_w_o_-_s_t_e_p_ _a_c_t_i_v_a_t_i_o_n_ _w_o_r_k_f_l_o_w
│ │ │ │  _P_r_e_v_i_o_u_s _N_e_x_t
│ │ ├── ./usr/share/doc/python-django-registration-doc/html/signals.html
│ │ │ @@ -113,15 +113,15 @@
│ │ │  workflows). Provides the following arguments:
      
│ │ │  
      
│ │ │  
      sender
      The ActivationView subclass used
│ │ │  to activate the user.
      
│ │ │  
      
│ │ │  
      user
      A user-model instance representing the activated account.
      
│ │ │  
      
│ │ │ -
      request
      The HttpRequest in which the account was
│ │ │ +
      request
      The HttpRequest in which the account was
│ │ │  activated.
      
│ │ │  
      
│ │ │  
      
│ │ │  
      This signal is automatically sent for you by the base
│ │ │  ActivationView, so unless
│ │ │  you’ve overridden its
│ │ │  get() method in a
│ │ │ @@ -135,15 +135,15 @@
│ │ │  arguments:
      
│ │ │  
      
│ │ │  
      sender
      The RegistrationView subclass used
│ │ │  to register the account.
      
│ │ │  
      
│ │ │  
      user
      A user-model instance representing the new account.
      
│ │ │  
      
│ │ │ -
      request
      The HttpRequest in which the new account
│ │ │ +
      request
      The HttpRequest in which the new account
│ │ │  was registered.
      
│ │ │  
      
│ │ │  
      
│ │ │  
      This signal is not automatically sent for you by the base
│ │ │  RegistrationView. It is sent by
│ │ │  the subclasses implemented for the three included registration
│ │ │  workflows, but if you write your own subclass of
│ │ │ ├── html2text {}
│ │ │ │ @@ -43,27 +43,27 @@
│ │ │ │        Sent when a user account is activated (not applicable to all workflows).
│ │ │ │        Provides the following arguments:
│ │ │ │          sender
│ │ │ │              The _A_c_t_i_v_a_t_i_o_n_V_i_e_w subclass used to activate the user.
│ │ │ │          user
│ │ │ │              A user-model instance representing the activated account.
│ │ │ │          request
│ │ │ │ -            The _H_t_t_p_R_e_q_u_e_s_t in which the account was activated.
│ │ │ │ +            The HttpRequest in which the account was activated.
│ │ │ │        This signal is automatically sent for you by the base _A_c_t_i_v_a_t_i_o_n_V_i_e_w, so
│ │ │ │        unless you’ve overridden its get() method in a subclass you should not
│ │ │ │        need to explicitly send it.
│ │ │ │    django_registration.signals.user_registered_¶
│ │ │ │        Sent when a new user account is registered. Provides the following
│ │ │ │        arguments:
│ │ │ │          sender
│ │ │ │              The _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w subclass used to register the account.
│ │ │ │          user
│ │ │ │              A user-model instance representing the new account.
│ │ │ │          request
│ │ │ │ -            The _H_t_t_p_R_e_q_u_e_s_t in which the new account was registered.
│ │ │ │ +            The HttpRequest in which the new account was registered.
│ │ │ │        This signal is nnoott automatically sent for you by the base
│ │ │ │        _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w. It is sent by the subclasses implemented for the three
│ │ │ │        included registration workflows, but if you write your own subclass of
│ │ │ │        _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w, you’ll need to send this signal as part of the
│ │ │ │        implementation of the _r_e_g_i_s_t_e_r_(_) method.
│ │ │ │  _P_r_e_v_i_o_u_s _N_e_x_t
│ │ │ │  ===============================================================================
│ │ ├── ./usr/share/doc/python-django-registration-doc/html/upgrade.html
│ │ │ @@ -146,15 +146,15 @@
│ │ │  2020, and is no longer supported. Django 3.0 reached the end of its
│ │ │  upstream support cycle in May 2021, and is no longer supported.
      
│ │ │
│ │ │
│ │ │

django-registration 3.1.2

│ │ │

This release fixes a security issue with low severity.

│ │ │

Prior to 3.1.2, django-registration did not apply Django’s │ │ │ -sensitive_post_parameters() │ │ │ +sensitive_post_parameters() │ │ │ decorator to the base │ │ │ RegistrationView. This meant that │ │ │ if detailed error reports, such as Django’s error reports emailed to │ │ │ site staff, │ │ │ were enabled, and a server-side error occurred during account │ │ │ registration, the generated error report would include all fields │ │ │ submitted in the HTTP request, some of which are potentially sensitive │ │ │ @@ -170,15 +170,15 @@ │ │ │ user model, but without explicitly subclassing │ │ │ RegistrationForm to point to │ │ │ that user model, previously the result would be a cryptic exception │ │ │ and error message raised from within Django, complaining about │ │ │ trying to work with the swapped-out user │ │ │ model. RegistrationView now │ │ │ explicitly raises │ │ │ -ImproperlyConfigured with an │ │ │ +ImproperlyConfigured with an │ │ │ informative error message to make it clear what has happened, and │ │ │ directs the developer to the documentation for using custom user │ │ │ models in django-registration.

│ │ │

  • A new validator, │ │ │ HTML5EmailValidator, is │ │ │ included and is applied by default to the email field of │ │ │ RegistrationForm. The HTML5 │ │ │ @@ -202,15 +202,15 @@ │ │ │

    Changes between django-registration 2.x and 3.x

    │ │ │
    │ │ │

    Module renaming

    │ │ │

    Prior to 3.x, django-registration installed a Python module named │ │ │ registration. To avoid silent incompatibilities, and to conform to │ │ │ more recent best practices, django-registration 3.x now installs a │ │ │ module named django_registration. Attempts to import from the │ │ │ -registration module will immediately fail with ImportError.

    │ │ │ +registration module will immediately fail with ImportError.

    │ │ │

    Many installations will be able to adapt by replacing references to │ │ │ registration with references to django_registration.

    │ │ │
    │ │ │
    │ │ │

    Removal of model-based workflow

    │ │ │

    The two-step model-based signup workflow, which has been present since │ │ │ the first public release of django-registration in 2007, has now been │ │ │ @@ -236,15 +236,15 @@ │ │ │

    Prior to 3.x, django-registration’s default URLconf modules for its │ │ │ built-in workflows would attempt to include the Django auth views │ │ │ (login, logout, password reset, etc.) for you. This became untenable │ │ │ with the rewrite of Django’s auth views to be class-based, as it │ │ │ required detecting the set of auth views and choosing a set of URL │ │ │ patterns at runtime.

    │ │ │

    As a result, auth views are no longer automatically configured for │ │ │ -you; if you want them, include() the URLconf │ │ │ +you; if you want them, include() the URLconf │ │ │ django.contrib.auth.urls at a location of your choosing.

    │ │ │
    │ │ │
    │ │ │

    Distinguishing activation failure conditions

    │ │ │

    Prior to 3.x, failures to activate a user account (in workflows which │ │ │ use activation) all simply returned None in place of the activated │ │ │ account. This meant it was not possible to determine, from inspecting │ │ │ @@ -259,16 +259,16 @@ │ │ │

    │ │ │

    Changes to custom user support

    │ │ │

    Support for custom user models has been brought more in line with the │ │ │ features Django offers. This affects compatibility of custom user │ │ │ models with django-registration’s default forms and views. In │ │ │ particular, custom user models should now provide, in addition to │ │ │ USERNAME_FIELD, the │ │ │ -get_username() and │ │ │ -get_email_field_name() │ │ │ +get_username() and │ │ │ +get_email_field_name() │ │ │ methods. See the custom user documentation for │ │ │ details.

    │ │ │
    │ │ │
    │ │ │

    Changes to success_url

    │ │ │

    Both the registration and activation views mimic Django’s own generic │ │ │ views in supporting a choice of ways to specify where to redirect │ │ │ @@ -279,42 +279,42 @@ │ │ │ get_success_url() │ │ │ . However, there is a key difference between the base Django │ │ │ generic-view version of this, and the version in django-registration: │ │ │ when calling a │ │ │ get_success_url() │ │ │ method, django-registration passes the user account as an argument.

    │ │ │

    This is incompatible with the behavior of Django’s base │ │ │ -FormMixin, which expects │ │ │ -get_success_url() to take │ │ │ +FormMixin, which expects │ │ │ +get_success_url() to take │ │ │ zero arguments.

    │ │ │

    Also, earlier versions of django-registration allowed │ │ │ success_url and │ │ │ get_success_url() to │ │ │ provide either a string URL, or a tuple of (viewname, args, │ │ │ -kwargs) to pass to Django’s reverse() helper, in │ │ │ +kwargs) to pass to Django’s reverse() helper, in │ │ │ order to work around issues caused by calling │ │ │ -reverse() at the level of a class attribute.

    │ │ │ +reverse() at the level of a class attribute.

    │ │ │

    In django-registration 3.x, the user argument to │ │ │ get_success_url() is │ │ │ -now optional, meaning FormMixin’s │ │ │ +now optional, meaning FormMixin’s │ │ │ default behavior is now compatible with any │ │ │ get_success_url() │ │ │ implementation that doesn’t require the user object; as a result, │ │ │ implementations which don’t rely on the user object should either │ │ │ switch to specifying │ │ │ success_url as an │ │ │ attribute, or change their own signature to get_success_url(self, │ │ │ user=None).

    │ │ │

    Also, the ability to supply the 3-tuple of arguments for │ │ │ -reverse() has been removed; both │ │ │ +reverse() has been removed; both │ │ │ success_url and │ │ │ get_success_url() │ │ │ now must be/return either a string, or a lazy object that resolves │ │ │ to a string. To avoid class-level calls to │ │ │ -reverse(), use django.urls.reverse_lazy() │ │ │ +reverse(), use django.urls.reverse_lazy() │ │ │ instead.

    │ │ │
    │ │ │
    │ │ │

    Removed “no free email” form

    │ │ │

    Earlier versions of django-registration included a form class, │ │ │ RegistrationFormNoFreeEmail, which attempted to forbid user │ │ │ signups using common free/throwaway email providers. Since this is a │ │ │ ├── html2text {} │ │ │ │ @@ -63,29 +63,29 @@ │ │ │ │ * Django 2.2, 3.1, and 3.2, on Python 3.6, 3.7, 3.8, and 3.9. │ │ │ │ Python 3.5 reached the end of its upstream support cycle in September 2020, and │ │ │ │ is no longer supported. Django 3.0 reached the end of its upstream support │ │ │ │ cycle in May 2021, and is no longer supported. │ │ │ │ ******** ddjjaannggoo--rreeggiissttrraattiioonn 33..11..22_?¶ ******** │ │ │ │ This release fixes a security issue with low severity. │ │ │ │ Prior to 3.1.2, django-registration did not apply Django’s │ │ │ │ -_s_e_n_s_i_t_i_v_e___p_o_s_t___p_a_r_a_m_e_t_e_r_s_(_) decorator to the base _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w. This meant │ │ │ │ +sensitive_post_parameters() decorator to the base _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w. This meant │ │ │ │ that if detailed error reports, such as _D_j_a_n_g_o_’_s_ _e_r_r_o_r_ _r_e_p_o_r_t_s_ _e_m_a_i_l_e_d_ _t_o_ _s_i_t_e │ │ │ │ _s_t_a_f_f, were enabled, and a server-side error occurred during account │ │ │ │ registration, the generated error report would include all fields submitted in │ │ │ │ the HTTP request, some of which are potentially sensitive depending on the │ │ │ │ user-account model and registration workflow in use. │ │ │ │ This issue is CVE-2021-21416 and GitHub security advisory GHSA-58c7-px5v-82hh. │ │ │ │ Thanks to Martin Morgenstern for reporting this issue. │ │ │ │ ******** DDjjaannggoo--rreeggiissttrraattiioonn 33..11_?¶ ******** │ │ │ │ * When an attempt was made to use django-registration with a custom user │ │ │ │ model, but wwiitthhoouutt explicitly subclassing _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m to point to │ │ │ │ that user model, previously the result would be a cryptic exception and │ │ │ │ error message raised from within Django, complaining about trying to work │ │ │ │ with the swapped-out user model. _R_e_g_i_s_t_r_a_t_i_o_n_V_i_e_w now explicitly raises │ │ │ │ - _I_m_p_r_o_p_e_r_l_y_C_o_n_f_i_g_u_r_e_d with an informative error message to make it clear │ │ │ │ + ImproperlyConfigured with an informative error message to make it clear │ │ │ │ what has happened, and directs the developer to the documentation for │ │ │ │ using custom user models in django-registration. │ │ │ │ * A new validator, _H_T_M_L_5_E_m_a_i_l_V_a_l_i_d_a_t_o_r, is included and is applied by │ │ │ │ default to the email field of _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m. The HTML5 email address │ │ │ │ grammar is more restrictive than the RFC grammar, but primarily in │ │ │ │ disallowing rare and problematic features. │ │ │ │ * Support for Python 2 was dropped, as Python 2 is EOL as of 2020-01-01. As │ │ │ │ @@ -97,15 +97,15 @@ │ │ │ │ itself compatible with Python 3.7 and with django 2.2. │ │ │ │ ********** CChhaannggeess bbeettwweeeenn ddjjaannggoo--rreeggiissttrraattiioonn 22..xx aanndd 33..xx_?¶ ********** │ │ │ │ ******** MMoodduullee rreennaammiinngg_?¶ ******** │ │ │ │ Prior to 3.x, django-registration installed a Python module namedregistration. │ │ │ │ To avoid silent incompatibilities, and to conform to more recent best │ │ │ │ practices, django-registration 3.x now installs a module │ │ │ │ nameddjango_registration. Attempts to import from theregistrationmodule will │ │ │ │ -immediately fail with _I_m_p_o_r_t_E_r_r_o_r. │ │ │ │ +immediately fail with ImportError. │ │ │ │ Many installations will be able to adapt by replacing references │ │ │ │ toregistrationwith references todjango_registration. │ │ │ │ ******** RReemmoovvaall ooff mmooddeell--bbaasseedd wwoorrkkffllooww_?¶ ******** │ │ │ │ The two-step model-based signup workflow, which has been present since the │ │ │ │ first public release of django-registration in 2007, has now been removed. In │ │ │ │ its place, it is recommended that you use _t_h_e_ _t_w_o_-_s_t_e_p_ _a_c_t_i_v_a_t_i_o_n_ _w_o_r_k_f_l_o_w │ │ │ │ instead, as that workflow requires no server-side storage of additional data │ │ │ │ @@ -120,55 +120,55 @@ │ │ │ │ ******** RReemmoovvaall ooff aauutthh UURRLLss_?¶ ******** │ │ │ │ Prior to 3.x, django-registration’s default URLconf modules for its built-in │ │ │ │ workflows would attempt to include the Django auth views (login, logout, │ │ │ │ password reset, etc.) for you. This became untenable with the rewrite of │ │ │ │ Django’s auth views to be class-based, as it required detecting the set of auth │ │ │ │ views and choosing a set of URL patterns at runtime. │ │ │ │ As a result, auth views are no longer automatically configured for you; if you │ │ │ │ -want them, _i_n_c_l_u_d_e_(_) the URLconfdjango.contrib.auth.urlsat a location of your │ │ │ │ +want them, include() the URLconfdjango.contrib.auth.urlsat a location of your │ │ │ │ choosing. │ │ │ │ ******** DDiissttiinngguuiisshhiinngg aaccttiivvaattiioonn ffaaiilluurree ccoonnddiittiioonnss_?¶ ******** │ │ │ │ Prior to 3.x, failures to activate a user account (in workflows which use │ │ │ │ activation) all simply returnedNonein place of the activated account. This │ │ │ │ meant it was not possible to determine, from inspecting the result, what │ │ │ │ exactly caused the failure. │ │ │ │ In django-registration 3.x, activation failures raise an exception – │ │ │ │ _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r – with a message and code (such as“expired”), to indicate the │ │ │ │ cause of failure. This exception is caught by _A_c_t_i_v_a_t_i_o_n_V_i_e_w and turned into │ │ │ │ the template context variableactivation_error. │ │ │ │ ******** CChhaannggeess ttoo ccuussttoomm uusseerr ssuuppppoorrtt_?¶ ******** │ │ │ │ Support for custom user models has been brought more in line with the features │ │ │ │ Django offers. This affects compatibility of custom user models with django- │ │ │ │ registration’s default forms and views. In particular, custom user models │ │ │ │ -should now provide, in addition to USERNAME_FIELD, the _g_e_t___u_s_e_r_n_a_m_e_(_) and │ │ │ │ -_g_e_t___e_m_a_i_l___f_i_e_l_d___n_a_m_e_(_) methods. See _t_h_e_ _c_u_s_t_o_m_ _u_s_e_r_ _d_o_c_u_m_e_n_t_a_t_i_o_n for details. │ │ │ │ +should now provide, in addition to USERNAME_FIELD, the get_username() and │ │ │ │ +get_email_field_name() methods. See _t_h_e_ _c_u_s_t_o_m_ _u_s_e_r_ _d_o_c_u_m_e_n_t_a_t_i_o_n for details. │ │ │ │ ******** CChhaannggeess ttoossuucccceessss__uurrll_?¶ ******** │ │ │ │ Both the registration and activation views mimic Django’s own generic views in │ │ │ │ supporting a choice of ways to specify where to redirect after a successful │ │ │ │ registration or activation; you can either set the attribute _s_u_c_c_e_s_s___u_r_l on the │ │ │ │ view class, or implement the method _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) . However, there is a key │ │ │ │ difference between the base Django generic-view version of this, and the │ │ │ │ version in django-registration: when calling a _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) method, │ │ │ │ django-registration passes the user account as an argument. │ │ │ │ -This is incompatible with the behavior of Django’s base _F_o_r_m_M_i_x_i_n, which │ │ │ │ -expects _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) to take zero arguments. │ │ │ │ +This is incompatible with the behavior of Django’s base FormMixin, which │ │ │ │ +expects get_success_url() to take zero arguments. │ │ │ │ Also, earlier versions of django-registration allowed _s_u_c_c_e_s_s___u_r_l and │ │ │ │ _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) to provide either a string URL, or a tuple of(viewname, args, │ │ │ │ -kwargs)to pass to Django’s _r_e_v_e_r_s_e_(_) helper, in order to work around issues │ │ │ │ -caused by calling _r_e_v_e_r_s_e_(_) at the level of a class attribute. │ │ │ │ +kwargs)to pass to Django’s reverse() helper, in order to work around issues │ │ │ │ +caused by calling reverse() at the level of a class attribute. │ │ │ │ In django-registration 3.x, theuserargument to _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) is now │ │ │ │ -optional, meaning _F_o_r_m_M_i_x_i_n’s default behavior is now compatible with any │ │ │ │ +optional, meaning FormMixin’s default behavior is now compatible with any │ │ │ │ _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) implementation that doesn’t require the user object; as a │ │ │ │ result, implementations which don’t rely on the user object should either │ │ │ │ switch to specifying _s_u_c_c_e_s_s___u_r_l as an attribute, or change their own signature │ │ │ │ toget_success_url(self, user=None). │ │ │ │ -Also, the ability to supply the 3-tuple of arguments for _r_e_v_e_r_s_e_(_) has been │ │ │ │ +Also, the ability to supply the 3-tuple of arguments for reverse() has been │ │ │ │ removed; both _s_u_c_c_e_s_s___u_r_l and _g_e_t___s_u_c_c_e_s_s___u_r_l_(_) now mmuusstt be/return either a │ │ │ │ string, or a lazy object that resolves to a string. To avoid class-level calls │ │ │ │ -to _r_e_v_e_r_s_e_(_), usedjango.urls.reverse_lazy()instead. │ │ │ │ +to reverse(), usedjango.urls.reverse_lazy()instead. │ │ │ │ ******** RReemmoovveedd ?“nnoo ffrreeee eemmaaiill?” ffoorrmm_?¶ ******** │ │ │ │ Earlier versions of django-registration included a form │ │ │ │ class,RegistrationFormNoFreeEmail, which attempted to forbid user signups using │ │ │ │ common free/throwaway email providers. Since this is a pointless task (the │ │ │ │ number of possible domains of such providers is ever-growing), this form class │ │ │ │ has been removed. │ │ │ │ ******** TTeemmppllaattee nnaammeess_?¶ ******** │ │ ├── ./usr/share/doc/python-django-registration-doc/html/validators.html │ │ │ @@ -116,15 +116,15 @@ │ │ │

    │ │ │
    │ │ │ django_registration.validators.DUPLICATE_USERNAME
    │ │ │

    Error message raised by │ │ │ CaseInsensitiveValidator │ │ │ when the supplied username is not unique. This is the same string │ │ │ raised by Django’s default │ │ │ -User model for a non-unique │ │ │ +User model for a non-unique │ │ │ username.

    │ │ │
    │ │ │ │ │ │
    │ │ │
    │ │ │ django_registration.validators.RESERVED_NAME
    │ │ │

    Error message raised by │ │ │ @@ -173,18 +173,18 @@ │ │ │ want to disallow.

    │ │ │

    The default list of reserved names, if you don’t specify one, is │ │ │ DEFAULT_RESERVED_NAMES. The │ │ │ validator will also reject any value beginning with the string │ │ │ “.well-known” (see RFC 5785).

    │ │ │
    │ │ │
    Parameters
    │ │ │ -

    reserved_names (list) – A list of reserved names to forbid.

    │ │ │ +

    reserved_names (list) – A list of reserved names to forbid.

    │ │ │
    │ │ │
    Raises
    │ │ │ -

    django.core.exceptions.ValidationError – if the provided │ │ │ +

    django.core.exceptions.ValidationError – if the provided │ │ │ value is reserved.

    │ │ │
    │ │ │
    │ │ │
    │ │ │ │ │ │

    Several constants are provided which are used by this validator:

    │ │ │
    │ │ │ @@ -266,19 +266,19 @@ │ │ │ Unicode ‘Script’ property) which also contains one or more │ │ │ characters that appear in the Unicode Visually Confusable │ │ │ Characters file.

    │ │ │

    This validator is enabled by default on the username field of │ │ │ registration forms.

    │ │ │
    │ │ │
    Parameters
    │ │ │ -

    value (str) – The username value to validate (non-string │ │ │ +

    value (str) – The username value to validate (non-string │ │ │ usernames will not be checked)

    │ │ │
    │ │ │
    Raises
    │ │ │ -

    django.core.exceptions.ValidationError – if the value is mixed-script confusable

    │ │ │ +

    django.core.exceptions.ValidationError – if the value is mixed-script confusable

    │ │ │
    │ │ │
    │ │ │
    │ │ │ │ │ │
    │ │ │
    │ │ │ django_registration.validators.validate_confusables_email(value)
    │ │ │ @@ -290,18 +290,18 @@ │ │ │ a mixed-script value (as defined by Unicode ‘Script’ property) │ │ │ which also contains one or more characters that appear in the │ │ │ Unicode Visually Confusable Characters file.

    │ │ │

    This validator is enabled by default on the email field of │ │ │ registration forms.

    │ │ │
    │ │ │
    Parameters
    │ │ │ -

    value (str) – The email address to validate

    │ │ │ +

    value (str) – The email address to validate

    │ │ │
    │ │ │
    Raises
    │ │ │ -

    django.core.exceptions.ValidationError – if the value is mixed-script confusable

    │ │ │ +

    django.core.exceptions.ValidationError – if the value is mixed-script confusable

    │ │ │
    │ │ │
    │ │ │
    │ │ │ │ │ │
    │ │ │
    │ │ │

    Other validators

    │ │ │ @@ -314,22 +314,22 @@ │ │ │ RegistrationFormCaseInsensitive │ │ │ for case-insensitive username uniqueness, and │ │ │ RegistrationFormUniqueEmail for │ │ │ unique email addresses.

    │ │ │
    │ │ │
    Parameters
    │ │ │
      │ │ │ -

    • model (django.db.models.Model) – The model class to query │ │ │ +

    • model (django.db.models.Model) – The model class to query │ │ │ against for uniqueness checks.

      • │ │ │ -

    • field_name (str) – The field name to perform the uniqueness │ │ │ +

    • field_name (str) – The field name to perform the uniqueness │ │ │ check against.

      • │ │ │
    │ │ │
    │ │ │
    Raises
    │ │ │ -

    django.core.exceptions.ValidationError – if the value is not │ │ │ +

    django.core.exceptions.ValidationError – if the value is not │ │ │ unique.

    │ │ │
    │ │ │
    │ │ │ │ │ │ │ │ │
    │ │ │
    │ │ │ ├── html2text {} │ │ │ │ @@ -37,15 +37,15 @@ │ │ │ │ translation; most have translations already provided in django-registration. │ │ │ │ django_registration.validators.DUPLICATE_EMAIL_¶ │ │ │ │ Error message raised by _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m_U_n_i_q_u_e_E_m_a_i_l when the supplied │ │ │ │ email address is not unique. │ │ │ │ django_registration.validators.DUPLICATE_USERNAME_¶ │ │ │ │ Error message raised by CaseInsensitiveValidator when the supplied │ │ │ │ username is not unique. This is the same string raised by Django’s │ │ │ │ - default _U_s_e_r model for a non-unique username. │ │ │ │ + default User model for a non-unique username. │ │ │ │ django_registration.validators.RESERVED_NAME_¶ │ │ │ │ Error message raised by _R_e_s_e_r_v_e_d_N_a_m_e_V_a_l_i_d_a_t_o_r when it is given a value │ │ │ │ that is a reserved name. │ │ │ │ django_registration.validators.TOS_REQUIRED_¶ │ │ │ │ Error message raised by _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m_T_e_r_m_s_O_f_S_e_r_v_i_c_e when the terms-of- │ │ │ │ service field is not checked. │ │ │ │ ********** RReejjeeccttiinngg ?“rreesseerrvveedd?” uusseerrnnaammeess_?¶ ********** │ │ │ │ @@ -70,17 +70,17 @@ │ │ │ │ If you want to supply your own custom list of reserved names, you can │ │ │ │ subclass _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m and set the attributereserved_namesto the list │ │ │ │ of values you want to disallow. │ │ │ │ The default list of reserved names, if you don’t specify one, is │ │ │ │ _D_E_F_A_U_L_T___R_E_S_E_R_V_E_D___N_A_M_E_S. The validator will also reject any value │ │ │ │ beginning with the string“.well-known”(see _R_F_C_ _5_7_8_5). │ │ │ │ Parameters │ │ │ │ - rreesseerrvveedd__nnaammeess (_ll_ii_ss_tt) – A list of reserved names to forbid. │ │ │ │ + rreesseerrvveedd__nnaammeess (lliisstt) – A list of reserved names to forbid. │ │ │ │ Raises │ │ │ │ - _dd_jj_aa_nn_gg_oo_.._cc_oo_rr_ee_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._VV_aa_ll_ii_dd_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if the provided value is │ │ │ │ + ddjjaannggoo..ccoorree..eexxcceeppttiioonnss..VVaalliiddaattiioonnEErrrroorr – if the provided value is │ │ │ │ reserved. │ │ │ │ Several constants are provided which are used by this validator: │ │ │ │ django_registration.validators.CA_ADDRESSES_¶ │ │ │ │ A list of email usernames commonly used by certificate authorities when │ │ │ │ verifying identity. │ │ │ │ django_registration.validators.NOREPLY_ADDRESSES_¶ │ │ │ │ A list of common email usernames used for automated messages from a Web │ │ │ │ @@ -118,50 +118,50 @@ │ │ │ │ usernames. │ │ │ │ This validator will reject any mixed-script value (as defined by Unicode │ │ │ │ ‘Script’ property) which also contains one or more characters that appear │ │ │ │ in the Unicode Visually Confusable Characters file. │ │ │ │ This validator is enabled by default on the username field of │ │ │ │ registration forms. │ │ │ │ Parameters │ │ │ │ - vvaalluuee (_ss_tt_rr) – The username value to validate (non-string usernames │ │ │ │ + vvaalluuee (ssttrr) – The username value to validate (non-string usernames │ │ │ │ will not be checked) │ │ │ │ Raises │ │ │ │ - _dd_jj_aa_nn_gg_oo_.._cc_oo_rr_ee_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._VV_aa_ll_ii_dd_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if the value is mixed- │ │ │ │ + ddjjaannggoo..ccoorree..eexxcceeppttiioonnss..VVaalliiddaattiioonnEErrrroorr – if the value is mixed- │ │ │ │ script confusable │ │ │ │ django_registration.validators.validate_confusables_email(vvaalluuee)_¶ │ │ │ │ A custom validator which prohibits the use of dangerously-confusable │ │ │ │ email address. │ │ │ │ This validator will reject any email address where either the local-part │ │ │ │ of the domain is – when considered in isolation – dangerously confusable. │ │ │ │ A string is dangerously confusable if it is a mixed-script value (as │ │ │ │ defined by Unicode ‘Script’ property) which also contains one or more │ │ │ │ characters that appear in the Unicode Visually Confusable Characters │ │ │ │ file. │ │ │ │ This validator is enabled by default on the email field of registration │ │ │ │ forms. │ │ │ │ Parameters │ │ │ │ - vvaalluuee (_ss_tt_rr) – The email address to validate │ │ │ │ + vvaalluuee (ssttrr) – The email address to validate │ │ │ │ Raises │ │ │ │ - _dd_jj_aa_nn_gg_oo_.._cc_oo_rr_ee_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._VV_aa_ll_ii_dd_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if the value is mixed- │ │ │ │ + ddjjaannggoo..ccoorree..eexxcceeppttiioonnss..VVaalliiddaattiioonnEErrrroorr – if the value is mixed- │ │ │ │ script confusable │ │ │ │ ********** OOtthheerr vvaalliiddaattoorrss_?¶ ********** │ │ │ │ ccllaassss django_registration.validators.CaseInsensitiveUnique(mmooddeell, │ │ │ │ ffiieelldd__nnaammee)_¶ │ │ │ │ A callable validator class (see _D_j_a_n_g_o_’_s_ _v_a_l_i_d_a_t_o_r_s_ _d_o_c_u_m_e_n_t_a_t_i_o_n) which │ │ │ │ enforces case-insensitive uniqueness on a given field of a particular │ │ │ │ model. Used by _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m_C_a_s_e_I_n_s_e_n_s_i_t_i_v_e for case-insensitive │ │ │ │ username uniqueness, and _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m_U_n_i_q_u_e_E_m_a_i_l for unique email │ │ │ │ addresses. │ │ │ │ Parameters │ │ │ │ - * mmooddeell (_dd_jj_aa_nn_gg_oo_.._dd_bb_.._mm_oo_dd_ee_ll_ss_.._MM_oo_dd_ee_ll) – The model class to query │ │ │ │ + * mmooddeell (ddjjaannggoo..ddbb..mmooddeellss..MMooddeell) – The model class to query │ │ │ │ against for uniqueness checks. │ │ │ │ - * ffiieelldd__nnaammee (_ss_tt_rr) – The field name to perform the uniqueness │ │ │ │ + * ffiieelldd__nnaammee (ssttrr) – The field name to perform the uniqueness │ │ │ │ check against. │ │ │ │ Raises │ │ │ │ - _dd_jj_aa_nn_gg_oo_.._cc_oo_rr_ee_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._VV_aa_ll_ii_dd_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if the value is not │ │ │ │ + ddjjaannggoo..ccoorree..eexxcceeppttiioonnss..VVaalliiddaattiioonnEErrrroorr – if the value is not │ │ │ │ unique. │ │ │ │ ccllaassss django_registration.validators.HTML5EmailValidator_¶ │ │ │ │ A callable validator class (see _D_j_a_n_g_o_’_s_ _v_a_l_i_d_a_t_o_r_s_ _d_o_c_u_m_e_n_t_a_t_i_o_n) which │ │ │ │ enforces the _H_T_M_L_5_ _e_m_a_i_l_ _a_d_d_r_e_s_s_ _f_o_r_m_a_t. The format used by HTML5’sinput │ │ │ │ type=”email”is deliberately more restrictive than what is permitted by │ │ │ │ the latest email RFCs; specifically, HTML5’s validation rule disallows a │ │ │ │ number of rare and problematic features – such as embedded comments and │ │ ├── ./usr/share/doc/python-django-registration-doc/html/views.html │ │ │ @@ -100,18 +100,18 @@ │ │ │ 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 │ │ │ +

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

    │ │ │

    Standard attributes and methods of │ │ │ -FormView can be overridden to │ │ │ +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)
    │ │ │ @@ -126,28 +126,28 @@ │ │ │ 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

    │ │ │ +

    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() │ │ │ +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 │ │ │ @@ -157,16 +157,16 @@ │ │ │

    │ │ │ │ │ │
    │ │ │
    │ │ │ 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 │ │ │ +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
    │ │ │ @@ -193,42 +193,42 @@ │ │ │ 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.

    │ │ │ +

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

    │ │ │
    │ │ │
    Return type
    │ │ │ -

    str

    │ │ │ +

    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

    │ │ │ +

    bool

    │ │ │
    │ │ │
    │ │ │
    │ │ │ │ │ │ │ │ │ │ │ │
    │ │ │
    │ │ │ class django_registration.views.ActivationView
    │ │ │

    A subclass of Django’s │ │ │ -TemplateView which provides │ │ │ +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 │ │ │ @@ -237,31 +237,31 @@ │ │ │ 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

    │ │ │ +

    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 │ │ │ +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
    │ │ │ @@ -275,18 +275,18 @@ │ │ │ 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.

    │ │ │ +

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

    │ │ │
    │ │ │
    Return type
    │ │ │ -

    str

    │ │ │ +

    str

    │ │ │
    │ │ │
    │ │ │
    │ │ │ │ │ │
    │ │ │ │ │ │
    │ │ │ ├── html2text {} │ │ │ │ @@ -32,17 +32,17 @@ │ │ │ │ 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. │ │ │ │ ccllaassss django_registration.views.RegistrationView_¶ │ │ │ │ - A subclass of Django’s _F_o_r_m_V_i_e_w which provides the infrastructure for │ │ │ │ + A subclass of Django’s FormView which provides the infrastructure for │ │ │ │ supporting user registration. │ │ │ │ - Standard attributes and methods of _F_o_r_m_V_i_e_w can be overridden to control │ │ │ │ + Standard attributes and methods of FormView can be overridden to control │ │ │ │ behavior as described in Django’s documentation, with the exception of │ │ │ │ _g_e_t___s_u_c_c_e_s_s___u_r_l_(_), which must use the signature documented below. │ │ │ │ When writing your own subclass, one method is required: │ │ │ │ register(ffoorrmm)_¶ │ │ │ │ Implement your registration logic here.formwill be the (already- │ │ │ │ validated) form filled out by the user during the registration │ │ │ │ process (i.e., a valid instance of _R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m or a subclass │ │ │ │ @@ -51,32 +51,32 @@ │ │ │ │ should send the signal _d_j_a_n_g_o___r_e_g_i_s_t_r_a_t_i_o_n_._s_i_g_n_a_l_s_._u_s_e_r___r_e_g_i_s_t_e_r_e_d. │ │ │ │ Note that this is not automatically done for you when writing your │ │ │ │ own custom subclass, so you must send this signal manually. │ │ │ │ Parameters │ │ │ │ ffoorrmm (_dd_jj_aa_nn_gg_oo____rr_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_.._ff_oo_rr_mm_ss_.._RR_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_FF_oo_rr_mm) – The │ │ │ │ registration form to use. │ │ │ │ Return type │ │ │ │ - _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_u_t_h_._m_o_d_e_l_s_._A_b_s_t_r_a_c_t_U_s_e_r │ │ │ │ + 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 │ │ │ │ - _r_e_v_e_r_s_e_(_) helper, or the lazy object produced by Django’s │ │ │ │ - _r_e_v_e_r_s_e___l_a_z_y_(_) helper. Default value is the result of calling │ │ │ │ - _r_e_v_e_r_s_e___l_a_z_y_(_) with the URL name‘registration_disallowed’. │ │ │ │ + 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 │ │ │ │ _d_j_a_n_g_o___r_e_g_i_s_t_r_a_t_i_o_n_._f_o_r_m_s_._R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m. │ │ │ │ success_url_¶ │ │ │ │ The URL to redirect to after successful registration. Can be a │ │ │ │ hard-coded string, the string resulting from calling Django’s │ │ │ │ - _r_e_v_e_r_s_e_(_) helper, or the lazy object produced by Django’s │ │ │ │ - _r_e_v_e_r_s_e___l_a_z_y_(_) helper. Can be overridden on a per-request basis │ │ │ │ + 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 isNone; 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 │ │ │ │ @@ -85,58 +85,58 @@ │ │ │ │ _d_j_a_n_g_o___r_e_g_i_s_t_r_a_t_i_o_n_._f_o_r_m_s_._R_e_g_i_s_t_r_a_t_i_o_n_F_o_r_m │ │ │ │ get_success_url(uusseerr)_¶ │ │ │ │ Return a URL to redirect to after successful registration, on a │ │ │ │ per-request or per-user basis. If not overridden, will use │ │ │ │ _s_u_c_c_e_s_s___u_r_l. Should return a value of the same type as _s_u_c_c_e_s_s___u_r_l │ │ │ │ (see above). │ │ │ │ Parameters │ │ │ │ - uusseerr (_dd_jj_aa_nn_gg_oo_.._cc_oo_nn_tt_rr_ii_bb_.._aa_uu_tt_hh_.._mm_oo_dd_ee_ll_ss_.._AA_bb_ss_tt_rr_aa_cc_tt_UU_ss_ee_rr) – The new user │ │ │ │ + uusseerr (ddjjaannggoo..ccoonnttrriibb..aauutthh..mmooddeellss..AAbbssttrraaccttUUsseerr) – The new user │ │ │ │ account. │ │ │ │ Return type │ │ │ │ - _s_t_r │ │ │ │ + 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 _R_E_G_I_S_T_R_A_T_I_O_N___O_P_E_N. │ │ │ │ Return type │ │ │ │ - _b_o_o_l │ │ │ │ + bool │ │ │ │ ccllaassss django_registration.views.ActivationView_¶ │ │ │ │ - A subclass of Django’s _T_e_m_p_l_a_t_e_V_i_e_w which provides support for a separate │ │ │ │ + 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(**aarrggss, ****kkwwaarrggss)_¶ │ │ │ │ Implement your activation logic here. You are free to configure │ │ │ │ your URL patterns to pass any set of positional or keyword │ │ │ │ arguments to _A_c_t_i_v_a_t_i_o_n_V_i_e_w, 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 _A_c_t_i_v_a_t_i_o_n_E_r_r_o_r (if activation │ │ │ │ was not successful). │ │ │ │ Return type │ │ │ │ - _d_j_a_n_g_o_._c_o_n_t_r_i_b_._a_u_t_h_._m_o_d_e_l_s_._A_b_s_t_r_a_c_t_U_s_e_r │ │ │ │ + django.contrib.auth.models.AbstractUser │ │ │ │ Raises │ │ │ │ _dd_jj_aa_nn_gg_oo____rr_ee_gg_ii_ss_tt_rr_aa_tt_ii_oo_nn_.._ee_xx_cc_ee_pp_tt_ii_oo_nn_ss_.._AA_cc_tt_ii_vv_aa_tt_ii_oo_nn_EE_rr_rr_oo_rr – if │ │ │ │ activation fails. │ │ │ │ Useful places to override or customize on an _A_c_t_i_v_a_t_i_o_n_V_i_e_w 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 _r_e_v_e_r_s_e_(_) │ │ │ │ - helper, or the lazy object produced by Django’s _r_e_v_e_r_s_e___l_a_z_y_(_) │ │ │ │ + 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 isNone; 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(uusseerr)_¶ │ │ │ │ Return a URL to redirect to after successful activation, on a per- │ │ │ │ request or per-user basis. If not overridden, will use _s_u_c_c_e_s_s___u_r_l. │ │ │ │ Should return a value of the same type as _s_u_c_c_e_s_s___u_r_l (see above). │ │ │ │ Parameters │ │ │ │ - uusseerr (_dd_jj_aa_nn_gg_oo_.._cc_oo_nn_tt_rr_ii_bb_.._aa_uu_tt_hh_.._mm_oo_dd_ee_ll_ss_.._AA_bb_ss_tt_rr_aa_cc_tt_UU_ss_ee_rr) – The │ │ │ │ + uusseerr (ddjjaannggoo..ccoonnttrriibb..aauutthh..mmooddeellss..AAbbssttrraaccttUUsseerr) – The │ │ │ │ activated user account. │ │ │ │ Return type │ │ │ │ - _s_t_r │ │ │ │ + str │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ =============================================================================== │ │ │ │ © Copyright 2007-2022, James Bennett. │ │ │ │ Built with _S_p_h_i_n_x using a _t_h_e_m_e provided by _R_e_a_d_ _t_h_e_ _D_o_c_s.