[Python-modules-commits] [python-django-registration] 03/11: Import python-django-registration_2.1.2.orig.tar.gz
Stephan Suerken
absurd at moszumanska.debian.org
Fri Jul 29 19:18:41 UTC 2016
This is an automated email from the git hooks/post-receive script.
absurd pushed a commit to branch master
in repository python-django-registration.
commit 4041fb4895e19e0a0e4a84086c011ee87e9a5a54
Author: Stephan Sürken <absurd at debian.org>
Date: Fri Jul 29 16:49:03 2016 +0000
Import python-django-registration_2.1.2.orig.tar.gz
---
LICENSE | 2 +-
PKG-INFO | 6 +-
README.rst | 4 +-
django_registration.egg-info/PKG-INFO | 6 +-
django_registration.egg-info/SOURCES.txt | 2 +
docs/conf.py | 4 +-
docs/custom-user.rst | 198 ++++++++++++---------
docs/faq.rst | 28 +--
docs/forms.rst | 10 ++
docs/hmac.rst | 10 +-
docs/index.rst | 1 +
docs/install.rst | 28 ++-
docs/model-workflow.rst | 29 ++-
docs/quickstart.rst | 30 ++--
docs/settings.rst | 4 +-
docs/signals.rst | 13 ++
docs/upgrade.rst | 18 +-
docs/validators.rst | 130 ++++++++++++++
docs/views.rst | 15 +-
registration/__init__.py | 2 +-
registration/admin.py | 11 +-
registration/auth_urls.py | 16 +-
registration/backends/hmac/urls.py | 6 +-
registration/backends/hmac/views.py | 7 +-
registration/backends/model_activation/urls.py | 6 +-
registration/backends/simple/urls.py | 4 +-
registration/forms.py | 58 ++++--
.../management/commands/cleanupregistration.py | 6 +-
registration/models.py | 50 ++++--
registration/tests/test_forms.py | 62 ++++++-
registration/tests/test_hmac_workflow.py | 9 +-
registration/tests/test_models.py | 89 +++++++++
registration/tests/test_simple_workflow.py | 3 +-
registration/validators.py | 182 +++++++++++++++++++
registration/views.py | 29 ++-
setup.py | 4 +-
36 files changed, 860 insertions(+), 222 deletions(-)
diff --git a/LICENSE b/LICENSE
index f8c707b..5f67d07 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2007-2015, James Bennett
+Copyright (c) 2007-2016, James Bennett
All rights reserved.
Redistribution and use in source and binary forms, with or without
diff --git a/PKG-INFO b/PKG-INFO
index 69e5f40..942f37e 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: django-registration
-Version: 2.0.4
+Version: 2.1.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
@@ -11,8 +11,8 @@ Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Framework :: Django
-Classifier: Framework :: Django :: 1.7
Classifier: Framework :: Django :: 1.8
+Classifier: Framework :: Django :: 1.9
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
@@ -22,7 +22,7 @@ Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.2
Classifier: Programming Language :: Python :: 3.3
Classifier: Programming Language :: Python :: 3.4
+Classifier: Programming Language :: Python :: 3.5
Classifier: Topic :: Utilities
diff --git a/README.rst b/README.rst
index d65a7e0..1c547f2 100644
--- a/README.rst
+++ b/README.rst
@@ -5,8 +5,8 @@
This is a fairly simple user-registration application for Django,
designed to make allowing user signups as painless as possible. It
-requires a functional installation of Django 1.7 or newer, but has no
+requires a functional installation of Django 1.8 or newer, but has no
other dependencies.
Full documentation is `available online
-<https://django-registration.readthedocs.org/>`_.
\ No newline at end of file
+<https://django-registration.readthedocs.org/>`_.
diff --git a/django_registration.egg-info/PKG-INFO b/django_registration.egg-info/PKG-INFO
index 69e5f40..942f37e 100644
--- a/django_registration.egg-info/PKG-INFO
+++ b/django_registration.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: django-registration
-Version: 2.0.4
+Version: 2.1.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
@@ -11,8 +11,8 @@ Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Framework :: Django
-Classifier: Framework :: Django :: 1.7
Classifier: Framework :: Django :: 1.8
+Classifier: Framework :: Django :: 1.9
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
@@ -22,7 +22,7 @@ Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.2
Classifier: Programming Language :: Python :: 3.3
Classifier: Programming Language :: Python :: 3.4
+Classifier: Programming Language :: Python :: 3.5
Classifier: Topic :: Utilities
diff --git a/django_registration.egg-info/SOURCES.txt b/django_registration.egg-info/SOURCES.txt
index fd2d48c..e711225 100644
--- a/django_registration.egg-info/SOURCES.txt
+++ b/django_registration.egg-info/SOURCES.txt
@@ -24,6 +24,7 @@ docs/settings.rst
docs/signals.rst
docs/simple-workflow.rst
docs/upgrade.rst
+docs/validators.rst
docs/views.rst
registration/__init__.py
registration/admin.py
@@ -33,6 +34,7 @@ registration/models.py
registration/runtests.py
registration/signals.py
registration/urls.py
+registration/validators.py
registration/views.py
registration/backends/__init__.py
registration/backends/default/__init__.py
diff --git a/docs/conf.py b/docs/conf.py
index 559122b..fd7fead 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -9,8 +9,8 @@ source_suffix = '.rst'
master_doc = 'index'
project = u'django-registration'
copyright = u'2007-2015, James Bennett'
-version = '2.0'
-release = '2.0.4'
+version = '2.1'
+release = '2.1.2'
exclude_trees = ['_build']
pygments_style = 'sphinx'
html_static_path = ['_static']
diff --git a/docs/custom-user.rst b/docs/custom-user.rst
index cc9aace..badf8b4 100644
--- a/docs/custom-user.rst
+++ b/docs/custom-user.rst
@@ -9,92 +9,130 @@ authentication system supported only its own built-in user model,
have introduced support for `custom user models
<https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a-custom-user-model>`_.
-It is possible to use ``django-registration`` with a custom user
-model, so long as certain factors are accounted for.
-
-.. warning:: **Using email address as username**
-
- If your custom user model treats the email address as a username,
- or otherwise does not have distinct email address and username
- fields, you **must** write a custom registration workflow including
- custom registration form; the built-in workflows of
- ``django-registration`` will not function with a user model which
- uses the email address as a username.
-
-
-Writing a custom registration workflow
---------------------------------------
-
-The most straightforward way to guarantee compatibility with a custom
-user model is simply to write your own custom registration workflow,
-subclassing :class:`~registration.views.RegistrationView`,
-:class:`~registration.views.ActivationView`, and
-:class:`~registration.forms.RegistrationForm` as necessary. Refer to
-the documentation for those classes for notes on how to customize
-them.
-
-
-Using the built-in workflows
-----------------------------
-
-If you want to use one of the registration workflows built in to
-``django-registration``, there is some accommodation for custom user
-models. :ref:`The two-step model workflow <model-workflow>` uses a
-model with a ``OneToOneField`` to the user model, and uses the
-recommended practice of referring to it via the ``AUTH_USER_MODEL``
-setting. All built-in workflows also avoid importing or directly
-referring to Django's default user model, instead using the
-``get_user_model()`` helper provided in ``django.contrib.auth`` to
-obtain a reference to whatever model has been specified to represent
-users.
-
-However, all of these workflows do make some assumptions about the
-structure of your user model.
-
-The two-step workflows (both model-based and :ref:`HMAC-based
-<hmac-workflow>`) require that your user model define the following
-fields, which are found on Django's default user model:
+Older versions of ``django-registration`` did not generally support
+custom user models due to the additional complexity required; as of
+version |version|, however, ``django-registration`` now can support
+custom user models. Depending on how significantly your custom user
+model differs from Django's default, you may need to change only a few
+lines of code; custom user models significantly different from the
+default model may require more work to support.
+
+
+Overview
+--------
+
+The primary issue when using ``django-registration`` with a custom
+user model will be
+:class:`~registration.forms.RegistrationForm`. ``RegistrationForm`` is
+a subclass of Django's built-in ``UserCreationForm``, which in turn is
+a ``ModelForm`` with its model set to
+``django.contrib.auth.models.User``. The only changes made by
+``django-registration`` are to apply the reserved name validator
+(:class:`registration.validators.ReservedNameValidator`) and make the
+``email`` field required (by default, Django's user model makes this
+field optional; it is required in ``RegistrationForm`` because two of
+the three built-in workflows of ``django-registration`` require an
+email address in order to send account-activation instructions to the
+user). As a result, you will always be required to supply a custom
+form class when using ``django-registration`` with a custom user
+model.
+
+In the case where your user model is compatible with the default
+behavior of ``django-registration``, (see below) you will be able to
+simply subclass ``RegistrationForm``, set it to use your custom user
+model as the model, and then configure the views in
+``django-registration`` to use your form subclass. For example, you
+might do the following (in a ``forms.py`` module somewhere in your
+codebase -- do **not** directly edit ``django-registration``'s code):
+
+.. code-block:: python
+
+ from registration.forms import RegistrationForm
+
+ from mycustomuserapp.models import MyCustomUser
+
+
+ class MyCustomUserForm(RegistrationForm):
+ class Meta:
+ model = MyCustomUser
+
+And then in your URL configuration (example here uses the HMAC
+activation workflow):
+
+.. code-block:: python
+
+ from django.conf.urls import include, url
+
+ from registration.backends.hmac.views import RegistrationView
+
+ from mycustomuserapp.forms import MyCustomUserForm
+
+
+ urlpatterns = [
+ # ... other URL patterns here
+ url(r'^accounts/register/$',
+ RegistrationView.as_view(
+ form_class=MyCustomUserForm
+ ),
+ name='registration_register',
+ ),
+ url(r'^accounts/', include('registration.backends.hmac.urls')),
+ ]
+
+If your custom user model is not compatible with the built-in
+workflows of ``django-registration`` (see next section), you will
+probably need to subclass the provided views (either the base
+registration views, or the views of the workflow you want to use) and
+make the appropriate changes for your user model.
+
+
+Determining compatibility of a custom user model
+------------------------------------------------
+
+The built-in workflows and other code of ``django-registration`` do as
+much as is possible to ensure compatibility with custom user models;
+``django.contrib.auth.models.User`` is never directly imported or
+referred to, and all code in ``django-registration`` instead uses
+``settings.AUTH_USER_MODEL`` or
+``django.contrib.auth.get_user_model()`` to refer to the user model,
+and ``USERNAME_FIELD`` when access to the username is required.
+
+However, there are still some specific requirements you'll want to be
+aware of.
+
+The two-step activation workflows -- both :ref:`HMAC <hmac-workflow>`-
+and :ref:`model <model-workflow>`-based -- require that your user
+model have the following fields:
* ``email`` -- a ``CharField`` or ``EmailField`` holding the user's
- email address. This field is required by
- :class:`~registration.forms.RegistrationForm`.
-
-* ``password`` -- a ``CharField`` holding the user's password.
+ email address. Note that this field is required by
+ ``RegistrationForm``, which is a difference from Django's default
+ ``UserCreationForm``.
* ``is_active`` -- a ``BooleanField`` indicating whether the user's
account is active.
-You also *must* specify the attribute ``USERNAME_FIELD`` on your
-custom user model to denote the field used as the username, and that
-field must accept string values.
+You also *must* specify the attribute ``USERNAME_FIELD`` on your user
+model to denote the field used as the username. Additionally, your
+user model must implement the ``email_user`` method for sending email
+to the user.
-Additionally, the model-based workflow requires this field:
+The model-based activation workflow requires one additional field:
* ``date_joined`` -- a ``DateField`` or ``DateTimeField`` indicating
- when the user joined the site.
-
-The model-based and HMAC workflows also require that the user model
-define a manager class named ``objects``, and that this manager class
-provide a method ``create_user``, which will create and return a user
-instance from the arguments ``USERNAME_FIELD``
-(``django-registration`` will use that to determine the name of the
-username field) ``email``, and ``password``, and require that the user
-model provide the ``email_user`` method on instances.
-
-The simple one-step workflow requires ``USERNAME_FIELD`` to be
-specified (and for that field to accept strings), requires ``email``
-and ``password`` fields, and requires the existence of an ``objects``
-manager defining ``create_user``, as in the two-step workflows.
-
-If your custom user model cannot meet these API requirements, your
-only option for using ``django-registration`` will be to write your
-own registration workflow.
-
-If you wish to write your own subclasses of the forms and views from
-the model-based workflow, but will be customizing them to an
-incompatible custom user model, also note that you **must not** add
-``registration`` to your ``INSTALLED_APPS`` setting, as doing so would
-install the default workflow's
-:class:`~registration.models.RegistrationProfile` model, which does
-make the above-noted assumptions about the structure of your user
-model.
\ No newline at end of file
+ when the user's account was registered.
+
+:ref:`The simple one-step workflow <simple-workflow>` requires that
+your user model set ``USERNAME_FIELD``, and requires that it define a
+field named ``password`` for storing the user's password; the
+combination of ``USERNAME_FIELD`` and ``password`` must be sufficient
+to log a user in. Also note that ``RegistrationForm`` requires the
+``email`` field, so either provide that field on your model or
+subclass ``RegistrationForm``.
+
+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 you'll need to
+specify the full list of fields to display in the ``fields`` option of
+your ``RegistrationForm`` subclass.
\ No newline at end of file
diff --git a/docs/faq.rst b/docs/faq.rst
index bbe5ad7..02a296f 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -20,7 +20,8 @@ General
sticks to making it easy to implement typical signup workflows
using Django's own user model and auth system (with some ability
to use custom user models), while apps like ``django-allauth``
- handle the vagaries of social authentication far more effectively.
+ handle integration with third-party authentication services far
+ more effectively.
**What license is django-registration under?**
@@ -35,10 +36,13 @@ General
**What versions of Django and Python are supported?**
- As of ``django-registration`` |version|, Django 1.7, 1.8 and 1.9
- are supported, on Python 2.7, 3.2, 3.3, 3.4 or 3.5 (though note
- that Django 1.9 drops support for Python 3.2 and 3.3, and many
- libraries which support Python 3 do not support Python 3.2).
+ As of ``django-registration`` |version|, Django 1.8 and 1.9 are
+ supported, on Python 2.7, 3.3, 3.4 or 3.5. Although Django 1.8
+ supported Python 3.2 at initial release, Python 3.2 is now at its
+ end-of-life and ``django-registration`` no longer supports it.
+
+ It is expected that ``django-registration`` |version| will also
+ work with Django 1.10 and Python 3.6 once they are released.
**I found a bug or want to make an improvement!**
@@ -57,7 +61,7 @@ General
**How secure is django-registration?**
- In the eight-year history of ``django-registration``, there have
+ In the nine-year history of ``django-registration``, there have
been no security issues reported which required new releases to
remedy. This doesn't mean, though, that ``django-registration`` is
perfectly secure: much will depend on ensuring best practices in
@@ -100,7 +104,7 @@ General
Additionally, the ``setup.cfg`` file included in
``django-registration`` provides configuration for `coverage.py
- <https://coverage.readthedocs.org/en/coverage-4.0.2/>`_, enabling
+ <https://coverage.readthedocs.org/>`_, enabling
easy recording and reporting of test coverage.
@@ -117,7 +121,7 @@ Installation and setup
No, for two reasons:
- 1. Providing default templates with an application is generally
+ 1. Providing default templates with an application is ranges from
hard to impossible, because different sites can have such
wildly different design and template structure. Any attempt to
provide templates which would work with all the possibilities
@@ -204,10 +208,10 @@ Tips and tricks
**How do I manually activate a user?**
- In the model-based workflow, a custom admin action is provided for
- this. In the admin for the ``RegistrationProfile`` model, click
- the checkbox for the user(s) you'd like to activate, then select
- the "Activate users" action.
+ In :ref:`the model-based workflow <model-workflow>`, a custom
+ admin action is provided for this. In the admin for the
+ ``RegistrationProfile`` model, click the checkbox for the user(s)
+ you'd like to activate, then select the "Activate users" action.
In the HMAC-based workflow, simply toggle the ``is_active`` field
of the user in the admin.
\ No newline at end of file
diff --git a/docs/forms.rst b/docs/forms.rst
index f58b3da..b80a963 100644
--- a/docs/forms.rst
+++ b/docs/forms.rst
@@ -48,6 +48,16 @@ workflows in mind, but may also be useful in other situations.
``password2`` field. This is a backwards-incompatible change from
``django-registration`` 1.0.
+ .. note:: **Validation of usernames**
+
+ Because it's a subclass of Django's ``UserCreationForm``,
+ ``RegistrationForm`` will inherit the base validation defined by
+ Django. It also adds a custom ``clean()`` method which applies
+ one custom validator:
+ :class:`~registration.validators.ReservedNameValidator`. See the
+ documentation for ``ReservedNameValidator`` for notes on why it
+ exists and how to customize its behavior.
+
.. class:: RegistrationFormTermsOfService
diff --git a/docs/hmac.rst b/docs/hmac.rst
index b6ba628..04c5355 100644
--- a/docs/hmac.rst
+++ b/docs/hmac.rst
@@ -66,13 +66,15 @@ views at a specific location in your URL hierarchy.
The default URL pattern for the activation view in
``registration.backends.hmac.urls`` handles this for you.
-This workflow makes use of up to three settings:
+This workflow makes use of up to three settings (click for details on
+each):
* :data:`~django.conf.settings.ACCOUNT_ACTIVATION_DAYS`
* :data:`~django.conf.settings.REGISTRATION_OPEN`
-* :data:`~django.conf.settings.REGISTRATION_SALT`
+* :data:`~django.conf.settings.REGISTRATION_SALT` (see also :ref:`note
+ below <salt-security>`)
By default, this workflow uses
:class:`registration.forms.RegistrationForm` as its form class for
@@ -229,7 +231,7 @@ In particular, the activation key is of the form::
encoded_username:timestamp:signature
-Where ``encoded_username`` is the username of the new account,
+where ``encoded_username`` is the username of the new account,
(URL-safe) base64-encoded, ``timestamp`` is a base62-encoded timestamp
of the time the user registered, and ``signature`` is a (URL-safe)
base64-encoded HMAC of the username and timestamp.
@@ -239,6 +241,8 @@ as the key for HMAC; additionally, it permits the specification of a
salt value which can be used to "namespace" different uses of HMAC
across a Django-powered site.
+.. _salt-security:
+
The HMAC activation workflow will use the value (a string) of the
setting :data:`~django.conf.settings.REGISTRATION_SALT` as the salt,
defaulting to the string ``"registration"`` if that setting is not
diff --git a/docs/index.rst b/docs/index.rst
index 11c6731..e9ced02 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -47,6 +47,7 @@ documentation listed below.
views
forms
custom-user
+ validators
settings
signals
diff --git a/docs/install.rst b/docs/install.rst
index b6cb99a..abe31d2 100644
--- a/docs/install.rst
+++ b/docs/install.rst
@@ -10,28 +10,22 @@ information on obtaining and installing Django, consult the `Django
download page <https://www.djangoproject.com/download/>`_, which
offers convenient packaged downloads and installation instructions.
-The |version| release of ``django-registration`` supports Django 1.7,
-1.8 and 1.9, on any Python version supported by those versions of
-Django:
+The |version| release of ``django-registration`` supports Django 1.8
+and 1.9, on any Python version supported by those versions of Django:
-* Django 1.7 supports Python 2.7, 3.2, 3.3 and 3.4.
-
-* Django 1.8 suports Python 2.7, 3.2, 3.3, 3.4 and 3.5.
+* Django 1.8 suports Python 2.7, 3.3, 3.4 and 3.5.
* Django 1.9 supports Python 2.7, 3.4 and 3.5.
-.. important:: **Python 3.2**
+It is expected that ``django-registration`` |version| will also work
+with Django 1.10 and Python 3.6 once they are released.
- Although Django 1.7 and 1.8 support Python 3.2, and
- ``django-registration`` |version| supports it, many Python
- libraries supporting Python 3 impose a minimum requirement of
- Python 3.3 (due to conveniences added in Python 3.3 which make
- supporting Python 2 and 3 in the same codebase much simpler).
+.. important:: **Python 3.2**
- As a result, use of Python 3.2 is discouraged; Django 1.9 has
- already dropped support for it, and a future release of
- ``django-registration`` will likely drop Python 3.2 support as
- well.
+ Although Django 1.8 supported Python 3.2 at the time of its
+ release, the Python 3.2 series has reached end-of-life, and as a
+ result support for Python 3.2 has been dropped from
+ ``django-registration`` as of |version|.
Normal installation
@@ -89,6 +83,6 @@ revision you want, and install it using ``python setup.py install``.
Next steps
----------
-To get up and running quickly, checkout :ref:`the quick start guide
+To get up and running quickly, check out :ref:`the quick start guide
<quickstart>`. For full documentation, see :ref:`the documentation
index <index>`.
\ No newline at end of file
diff --git a/docs/model-workflow.rst b/docs/model-workflow.rst
index 5944606..de9a687 100644
--- a/docs/model-workflow.rst
+++ b/docs/model-workflow.rst
@@ -159,6 +159,9 @@ the database, using the following model:
The number of days the user has to activate, taken from the
setting ``ACCOUNT_ACTIVATION_DAYS``.
+ ``user``
+ The user registering for the new account.
+
``site``
An object representing the site on which the account was
registered; depending on whether ``django.contrib.sites`` is
@@ -230,29 +233,25 @@ Additionally, :class:`RegistrationProfile` has a custom manager
:rtype: ``None``
- .. method:: create_inactive_user(username, email, password, site[, send_email])
+ .. method:: create_inactive_user(form, site, send_email=True)
Creates a new, inactive user account and an associated instance
of :class:`RegistrationProfile`, sends the activation email and
returns the new ``User`` object representing the account.
- :param username: The username to use for the new account.
- :type username: string
- :param email: The email address to use for the new account.
- :type email: string
- :param password: The password to use for the new account.
- :type password: string
+ :param form: A bound instance of a subclass of
+ :class:`~registration.forms.RegistrationForm` representing
+ the (already-validated) data the user is trying to register
+ with.
:param site: An object representing the site on which the
- account is being registered.
- :type site: ``django.contrib.sites.models.Site`` or
- ``django.contrib.sites.models.RequestSite``
- :param send_email: If ``True``, the activation email will be
- sent to the account (by calling
+ account is being registered. :type site:
+ ``django.contrib.sites.models.Site`` or
+ ``django.contrib.sites.models.RequestSite`` :param
+ send_email: If ``True``, the activation email will be sent to
+ the account (by calling
:meth:`RegistrationProfile.send_activation_email`). If
``False``, no email will be sent (but the account will still
- be inactive).
- :type send_email: bool
- :rtype: user
+ be inactive). :type send_email: bool :rtype: user
.. method:: create_profile(user)
diff --git a/docs/quickstart.rst b/docs/quickstart.rst
index 00937c9..769471f 100644
--- a/docs/quickstart.rst
+++ b/docs/quickstart.rst
@@ -23,15 +23,17 @@ installations. Those two are:
The guide below covers use of these two workflows.
-Before proceeding with either of the recommended built-in workflows,
-you'll need to ensure ``django.contrib.auth`` has been installed (by
-adding it to ``INSTALLED_APPS`` and running ``manage.py migrate`` to
-install needed database tables). Also, if you're making use of `a
-custom user model
-<https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a-custom-user-model>`_,
-you'll probably want to pause and read :ref:`the custom user
-compatibility guide <custom-user>` before using
-``django-registration``.
+.. important:: **Django's authentication system must be installed**
+
+ Before proceeding with either of the recommended built-in
+ workflows, you'll need to ensure ``django.contrib.auth`` has been
+ installed (by adding it to ``INSTALLED_APPS`` and running
+ ``manage.py migrate`` to install needed database tables). Also, if
+ you're making use of `a custom user model
+ <https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a-custom-user-model>`_,
+ you'll probably want to pause and read :ref:`the custom user
+ compatibility guide <custom-user>` before using
+ ``django-registration``.
Configuring the HMAC activation workflow
@@ -54,7 +56,7 @@ Begin by adding the following setting to your Django settings file:
site administrator manually activates it.
For example, you might have something like the following in your
-Django settings file::
+Django settings::
ACCOUNT_ACTIVATION_DAYS = 7 # One-week activation window; you may, of course, use a different value.
@@ -165,6 +167,9 @@ being used. This template has the following context:
The number of days remaining during which the account may be
activated.
+``user``
+ The user registering for the new account.
+
``site``
An object representing the site on which the user registered;
depending on whether ``django.contrib.sites`` is installed, this
@@ -188,6 +193,9 @@ following context:
The number of days remaining during which the account may be
activated.
+``user``
+ The user registering for the new account.
+
``site``
An object representing the site on which the user registered;
depending on whether ``django.contrib.sites`` is installed, this
@@ -236,7 +244,7 @@ structure:
urlpatterns = [
# Other URL patterns ...
- url(r'^accounts/', include('registration.simple.hmac.urls')),
+ url(r'^accounts/', include('registration.backends.simple.urls')),
# More URL patterns ...
]
diff --git a/docs/settings.rst b/docs/settings.rst
index c65a3e2..a7cd755 100644
--- a/docs/settings.rst
+++ b/docs/settings.rst
@@ -56,8 +56,8 @@ of several custom settings.
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; it is used solely as a way of namespacing HMAC
- usage.
+ to be kept secret; see ref:`the note about this salt value and
+ security <salt-security>` for details.
Used by:
diff --git a/docs/signals.rst b/docs/signals.rst
index da8ddc3..29e317f 100644
--- a/docs/signals.rst
+++ b/docs/signals.rst
@@ -39,6 +39,11 @@ signals.
``request``
The ``HttpRequest`` in which the account was activated.
+ This signal is automatically sent for you by the base
+ :class:`~registration.views.ActivationView`, so unless you've
+ overridden its ``get()`` method in a subclass you should not need
+ to explicitly send it.
+
.. data:: user_registered
@@ -54,3 +59,11 @@ signals.
``request``
The ``HttpRequest`` in which the new account was registered.
+
+ This signal is **not** automatically sent for you by the base
+ :class:`~registration.views.RegistrationView`. It is sent by the
+ subclasses implemented for the three included registration
+ workflows, but if you write your own subclass of
+ ``RegistrationView``, you'll need to send this signal as part of
+ the implementation of the
+ :meth:`~registration.views.RegistrationView.register` method.
\ No newline at end of file
diff --git a/docs/upgrade.rst b/docs/upgrade.rst
index 9785f59..b98c58b 100644
--- a/docs/upgrade.rst
+++ b/docs/upgrade.rst
@@ -4,7 +4,7 @@
Upgrading from previous versions
================================
-Prior to |version|, the last widely-deployed release of
+Prior to 2.0, the last widely-deployed release of
``django-registration`` was 0.8; a 1.0 release was published, and
|version| is mostly backwards-compatible with it, but 1.0 appears not
to have seen wide adoption. As such, this guide covers the process of
@@ -120,3 +120,19 @@ following changes need to be noted:
* As noted above, the password-mismatch error message is now attached
to the ``password2`` field rather than being a form-level error.
+
+
+Changes since 2.0
+-----------------
+
+Only one major change occurred between ``django-registration`` 2.0 and
+|version|: the addition of the
+:class:`~registration.validators.ReservedNameValidator`, which is now
+used by default on :class:`~registration.forms.RegistrationForm` and
+its subclasses.
+
+This is technically backwards-incompatible, since a set of usernames
+which previously could be registered now cannot be registered. If you
+need to allow users to register with usernames forbidden by this
+validator, see its documentation for notes on how to customize or
+disable it.
diff --git a/docs/validators.rst b/docs/validators.rst
new file mode 100644
index 0000000..d540da6
--- /dev/null
+++ b/docs/validators.rst
@@ -0,0 +1,130 @@
+.. _validators:
+.. module:: registration.validators
+
+Validation utilities
+====================
+
+To ease the process of validating user registration data,
+``django-registration`` includes some validation-related data and
+utilities in ``registration.validators``.
+
+The available error messages are:
+
+.. data:: DUPLICATE_EMAIL
+
+ Error message raised by
+ :class:`~registration.forms.RegistrationFormUniqueEmail` when the
+ supplied email address is not unique.
+
+.. data:: FREE_EMAIL
+
+ Error message raised by
+ :class:`~registration.forms.RegistrationFormNoFreeEmail` when the
+ supplied email address is rejected by its list of free-email
+ domains.
+
+.. data:: RESERVED_NAME
+
+ Error message raised by
+ :class:`~registration.validators.ReservedNameValidator` when it is
+ given a value that is a reserved name.
+
+.. data:: TOS_REQUIRED
+
+ Error message raised by
+ :class:`~registration.forms.RegistrationFormTermsOfService` when
+ the terms-of-service field is not checked.
+
+
+All of these error messages are marked for translation; most have
+translations into multiple languages already in
+``django-registration``.
+
+Additionally, one custom validator is provided:
+
+.. class:: ReservedNameValidator
+
+ A custom validator (see `Django's validators documentation
+ <https://docs.djangoproject.com/en/stable/ref/forms/validation/#using-validators>`_)
+ which prohibits the use of a reserved name as the value.
+
+ By default, this validator is applied to the username field of
+ :class:`registration.forms.RegistrationForm` and all of its
+ subclasses. The validator is applied in a form-level ``clean()``
+ method on ``RegistrationForm``, so to remove it (not recommended),
+ simply subclass ``RegistrationForm`` and override ``clean()``. For
+ no custom form-level validation, you could simply implement it as:
+
+ .. code-block:: python
+
+ def clean(self):
+ pass
+
+ If you want to supply your own custom list of reserved names, you
+ can subclass ``RegistrationForm`` and set the attribute
+ ``reserved_names`` to the list of values you want to disallow.
+
+ .. note:: **Why reserved names are reserved**
+
+ Many Web applications enable per-user URLs (to display account
+ information), and some may also create email addresses or even
+ subdomains, based on a user's username. While this is often
+ useful, it also represents a risk: a user might register a name
+ which conflicts with an important URL, email address or
+ subdomain, and this might give that user control over it.
+
+ ``django-registration`` includes a list of reserved names, and
+ rejects them as usernames by default, in order to avoid this
+ issue.
+
+ The default list of reserved names, if you don't specify one, is
+ :data:`~registration.validators.DEFAULT_RESERVED_NAMES`. The
+ validator will also reject any value beginning with the string
+ ``".well-known"`` (see `RFC 5785
+ <https://www.ietf.org/rfc/rfc5785.txt>`_).
+
+Several constants are provided which are used by this validator:
+
+.. data:: SPECIAL_HOSTNAMES
+
+ A list of hostnames with reserved or special meaning (such as
+ "autoconfig", used by some email clients to automatically discover
+ configuration data for a domain).
+
+.. data:: PROTOCOL_HOSTNAMES
+
+ A list of protocol-specific hostnames sites commonly want to
+ reserve, such as "www" and "mail".
+
+.. data:: CA_ADDRESSES
+
+ A list of email usernames commonly used by certificate authorities
+ when verifying identity.
+
+.. data:: RFC_2142
+
+ A list of common email usernames specified by `RFC 2142
+ <https://www.ietf.org/rfc/rfc2142.txt>`_.
+
+.. data:: NOREPLY_ADDRESSES
+
+ A list of common email usernames used for automated messages from a
+ Web site (such as "noreply" and "mailer-daemon").
+
+.. data:: SENSITIVE_FILENAMES
+
+ A list of common filenames with important meanings, such that
+ usernames should not be allowed to conflict with them (such as
+ "favicon.ico" and "robots.txt").
+
+.. data:: OTHER_SENSITIVE_NAMES
+
+ Other names, not covered by the above lists, which have the
+ potential to conflict with common URLs or subdomains, such as
+ "blog" and "docs".
+
+.. data:: DEFAULT_RESERVED_NAMES
+
+ A list made of the concatentation of all of the above lists, used
+ as the default set of reserved names for
+ :class:`~registration.validators.ReservedNameValidator`.
\ No newline at end of file
diff --git a/docs/views.rst b/docs/views.rst
index 23d2772..07393cc 100644
--- a/docs/views.rst
+++ b/docs/views.rst
@@ -38,7 +38,9 @@ classes, for use in writing your own custom subclasses.
This method should return the newly-registered user instance,
and should send the signal
- :data:`registration.signals.user_registered`.
+ :data:`registration.signals.user_registered`. Note that this is
+ not automatically done for you when writing your own custom
+ subclass, so you must send this signal manually.
Useful optional places to override or customize on a
``RegistrationView`` subclass are:
@@ -93,6 +95,17 @@ classes, for use in writing your own custom subclasses.
Should return a boolean indicating whether user registration is
allowed, either in general or for this specific request.
+ .. warning:: Implementing ``form_invalid()``
+
+ To work around `a potential performance issue in Django 1.9
+ <https://code.djangoproject.com/ticket/25548>`_,
+ ``RegistrationView`` implements the ``form_invalid()``
+ method. If you choose to override ``form_invalid()`` in a
+ subclass of ``RegistrationView``, be sure to read the
+ implementation and comments in the source code of
+ ``django-registration`` first. Note that Django 1.9.1, once
+ released, will not be affected by this bug.
+
.. class:: ActivationView
diff --git a/registration/__init__.py b/registration/__init__.py
index ea7d549..c185e77 100644
--- a/registration/__init__.py
+++ b/registration/__init__.py
@@ -1,4 +1,4 @@
-VERSION = (2, 0, 4, 'final', 0)
+VERSION = (2, 1, 2, 'final', 0)
def get_version():
diff --git a/registration/admin.py b/registration/admin.py
index d52028f..f07c7b3 100644
--- a/registration/admin.py
+++ b/registration/admin.py
@@ -7,7 +7,7 @@ setting, which should only occur if you are using the model-based
activation workflow.
"""
-
+from django.apps import apps
from django.contrib import admin
from django.contrib.sites.shortcuts import get_current_site
from django.utils.translation import ugettext_lazy as _
@@ -15,7 +15,6 @@ from django.utils.translation import ugettext_lazy as _
from registration.models import RegistrationProfile
- at admin.register(RegistrationProfile)
class RegistrationAdmin(admin.ModelAdmin):
actions = ['activate_users', 'resend_activation_email']
list_display = ('user', 'activation_key_expired')
@@ -30,7 +29,7 @@ class RegistrationAdmin(admin.ModelAdmin):
"""
for profile in queryset:
RegistrationProfile.objects.activate_user(profile.activation_key)
- activate_users.short_description = _("Activate users")
+ activate_users.short_description = _(u"Activate users")
def resend_activation_email(self, request, queryset):
"""
@@ -47,4 +46,8 @@ class RegistrationAdmin(admin.ModelAdmin):
profile.send_activation_email(
get_current_site(request)
)
- resend_activation_email.short_description = _("Re-send activation emails")
... 906 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-django-registration.git
More information about the Python-modules-commits
mailing list