LICENSE_FILE=	${WORKSRC}/LICENSE

The authors of django-registration (redux) can be found at

<https://github.com/macropin/django-registration/network/members>

-------------------------------------------------

The original author of django-registration was James Bennett

<james@b-list.org>, who may be found online at

<http://www.b-list.org/>.

Others who have contributed to the application:

* Samuel Adam (French translation)

* Jannis Leidel (German translation)

* Rapahel Hertzog (helpful suggestions on packaging and distribution)

* Panos Laganakos (Greek translation)

* Ilya Filippov and Andy Mikhailenko (Russian translation)

* Jarek Zgoda (Polish translation)

* Meir Kriheli (Hebrew translation)

* Italo Maia (Brazilian Portuguese translation)

* Shinya Okano (Japanese translation)

* A. Al-Ibrahim (Arabic translation)

* Ernesto Rico Schmidt (Spanish translation)

* Vladislav Mitov (Bulgarian translation)

* Leonardo Manuel Rocha (Argentinean Spanish translation)

* Emil Stenström (Swedish translation)

* Liang Feng (Chinese translations)

* Nebojsa Djordjevic (Serbian translation)

* Nicola Larosa (Italian translation)

* Joost Cassee (Dutch translation)

* Björn Kristinsson (Icelandic translation)

* Rune Bromer (Danish translation)

* Domen Kožar (Slovenian translation)

* Young Gyu Park (Korean translation)

* Flavio Curella (updated Italian translation)

* Jon Lønne (Bokmål translation)

* Carles Barrobés (Catalan translation)

* Nuno Mariz (Portuguese translation)

* Patrick Samson (French translation)

* Recep Kirmizi (Turkish translation)

* Mohsen Mansouryar (Persian translation)

* Jeffrey Long (Testing templates)

* Ilya Baryshev (Test app / config)

===================================

django-registration-redux changelog

===================================

Version 1.4, 21 February, 2016

-----------------------------

* BACKWARDS-INCOMPATIBLE CHANGE: Remove unnecessary `_RequestPassingFormView`.

  See `#56 <https://github.com/macropin/django-registration/pull/56>`_.

* Compatibility: Added support for Django 1.10

* Bugfix: Pass request object into `resend_activation_mail` so the email

  template can render the site URL with the correct schema (HTTP, HTTPS).

* Bugfix: Ensure `register` method has consistent arguments.

  See `#153 <https://github.com/macropin/django-registration/pull/153>`_.

* Enhancement: Add invoke tasks, requirements.txt file, and make wrapper to

  help developers get setup.

  See `#154 <https://github.com/macropin/django-registration/pull/154>`_.

Version 1.3, 12 January, 2016

-----------------------------

* Add support for Django 1.9. django-registration supports Django 1.7 and newer.

* Feature: Added `resend_activation_mail` method to `RegistrationManager`.

* Feature: Added support for additional registration forms;

  `RegistrationFormTOSAndUniqueEmail` and `RegistrationFormTOSAndNoFreeEmail`.

  See `#113 <https://github.com/macropin/django-registration/pull/113>`_.

* Bugfix: Properly extend the base registration template.

* Enhancement: Re-enable Python 3.3 support.

* Enhancement: Distinguish between account activation failure and attempted

  reactivation. See `#72 <https://github.com/macropin/django-registration/pull/72>`_.

* Bugfix: Install an unzipped package in order to support running migrations.

  See `#104 <https://github.com/macropin/django-registration/pull/104>`_.

* Feature: Added Thai, Hungarian, and Russian localizations.

* Feature: Added support for specifying template paths for activation email.

Version 1.2, 11 May, 2015

-------------------------

* BACKWARDS-INCOMPATIBLE CHANGE: When overriding the

  `registration/activation_email.txt` template, you must also now override the

  `registration/activation_email.html` template or set the setting

  (`REGISTRATION_EMAIL_HTML`) to `False`.

* BACKWARDS-INCOMPATIBLE CHANGE: An initial migration for Django > 1.7 has been

  provided. South users will need to configure a null migration with

  (`SOUTH_MIGRATION_MODULES`).

* BACKWARDS-INCOMPATIBLE CHANGE: A `base.html` template is now assumed to

  exist.

* Feature: Added support for disabling HTML emails using the setting option

  `REGISTRATION_EMAIL_HTML`.

* Feature: Added settings' options that allows to exlude the default auth urls

  (`INCLUDE_AUTH_URLS`) and register url (`INCLUDE_REGISTER_URL`).

* Feature: Added support to dynamically import any chosen registration form

  using the settings option `REGISTRATION_FORM`.

* Enhancement: Make `RegistrationForm` a subclass of Django's

  `UserCreationForm`

* Enhancement: Use registration form `save` method to create user instance,

  whenever form is a subclass of Django's `ModelForm`.

Version 1.1, 19 September, 2014

-------------------------------

This represents the first release of `django-registration-redux`.

It is based off the defunct v1.0 `django-registration` abandoned by James Bennett.

* Compatibility: Added support for Python 3.x.

* Compatibility: Added support for Django 1.6, 1.7.

* Feature: Added support for mime/multipart HTML / Text registration

  emails.

* Feature: Added `REGISTRATION_EMAIL_SUBJECT_PREFIX` config.

* Feature: Added support for `REGISTRATION_AUTO_LOGIN` config.

* Feature: Added support for `SEND_ACTIVATION_EMAIL` config.

* Bugfix: Signal "user_activated" was being sent twice.

* Bugfix: Fixed broken tests.

The change log below is from the versions maintained

by James Bennett.

Version 1.0, 17 June 2013

-------------------------

(Taken from release-notes.rst in this release)

* The 1.0 release of django-registration represents a complete

  rewrite of the previous codebase. For information on upgrading,

  consult :ref:`the upgrade guide <upgrade>`.

* The largest overall change is that in place of the monolithic backend

  classes and function-based views found in django-registration 0.8, in

  1.0 all views are class-based. A "backend" now consists of,

  typically, one or two subclasses of :ref:`the built-in base views

  <views>`.

* Implementing these as class-based views allows for far simpler

  configuration and customization, without the overhead involved in

  supporting large numbers of optional keyword arguments to

  function-based views, or the need to provide a separate class-based

  infrastructure for implementing the logic of registration.

* Notably, this implementation is also completely backwards-compatible

  for users of django-registration 0.8 who simply used the recommended

  default URLConf for one of the supplied backends; those URLConfs exist

  in the same locations, and have been rewritten to point to the

  appropriate class-based views with the appropriate options.

Version 0.8, 24 March 2012:

---------------------------

* Backend-based rewrite. See docs/upgrade.rst for details.

* Compatibility through Django 1.4.

Version 0.7, 6 November 2008:

-----------------------------

* Project hosting moved from Google Code to Bitbucket, and from a

  Subversion repository to Mercurial.

* Added test suite.

* Full Django 1.0 compatibility.

* Registration and activation views now accept an ``extra_context``

  argument, identical to the way that argument works in Django's

  generic views.

* Added a custom management command for cleaning up expired

  registrations; you can now run ``manage.py cleanupregistration`` to

  handle this.

* BACKWARDS-INCOMPATIBLE CHANGE: The "username" field in

  ``RegistrationForm`` is now a ``RegexField``.

* BACKWARDS-INCOMPATIBLE CHANGE: Removed the standalone script for

  deleting expired user registrations; use the new management command

  instead.

Version 0.6, 29 July 2008:

--------------------------

* Packaged from revision 166 in Subversion.

* Fixed a multiple-objects exception in

  ``RegistrationFormUniqueEmail`` when multiple users already have the

  same email address.

* Changed the ``success_url`` of the ``register()`` view to use

  reverse URL resolution.

* Added an ``extra_context`` argument to the ``register`` and

  ``activate`` views, mimicking its functionality in Django's generic

  views.

* BACKWARDS-INCOMPATIBLE CHANGE: Switched the admin declaration to be

  compliant with the newforms-admin refactor; the admin declaration

  now lives in ``registration/admin.py``.

* BACKWARDS-INCOMPATIBLE CHANGE: Switched form imports from using

  ``django.newforms`` to using ``django.forms``; the old style now

  raises a deprecation warning on Django trunk and on Django 1.0

  alpha.

Version 0.5, 4 June 2008:

-------------------------

* Packaged from revision 155 in Subversion.

* Added Serbian translation.

* Added Italian translation.

* Username/email uniqueness checks are now case-insensitive. This is

  potentially backwards-incompatible if you relied on them being

  case-sensitive, but I don't know of any reason why you'd be doing

  that.

* Included forms now use lazy translations.

* The ``register`` view can now handle files submitted for use in form

  processing.

* Reactivation of a manually-deactivated account is now prevented by

  changing the activation key, on successful activation, to a dummy

  string which will fail on subsequent activation attempts.

Version 0.4p2, 10 Feburary 2008:

--------------------------------

* Added Brazilian Portuguese translation.

* Added Japanese translation.

* Added Hebrew translation.

* Minor documentation fixes.

Version 0.4p1, 16 December 2007:

--------------------------------

* Packaged from revision 129 in Subversion.

* Added Polish translation.

Version 0.4, 8 December 2007:

-----------------------------

* Packaged from revision 122 in Subversion.

* Added Greek translation.

* Added Russian translation.

* Changed ``maxlength`` to ``max_length`` now that Django issues a

  deprecation warning for it.

* BACKWARDS-INCOMPATIBLE CHANGE: Changed the password validation to be

  on ``clean()`` instead of ``clean_password2()``. This means that

  errors from this must be accessed via ``non_field_errors()``.

Version 0.3p5, 6 October 2007:

------------------------------

* Packaged from revision 112 in Subversion.

* Added German translation.

* Fixed a mismatch between the default ``RegistrationForm``'s maximum

  length on email addresses and the actual maximum length on Django's

  ``User`` model.

* Fixed a situation where bad input for the ``password1`` field on

  ``RegistrationForm`` could cause validation of ``password2`` to fail

  with an exception.

Version 0.3p4, 4 October 2007:

------------------------------

* Packaged from revision 101 in Subversion.

* BACKWARDS-INCOMPATIBLE CHANGE: In response to larger numbers of

  complaints from people trying to use the example templates as-is,

  the example templates have been removed.

Version 0.3p2, 23 September 2007:

---------------------------------

* Packaged from revision 100 in Subversion.

* Fixed ``activate`` view to actually take the ``template_name``

  argument.

Version 0.3p1, 22 September 2007:

---------------------------------

* Packaged from revision 99 in Subversion.

* Fixed a typo in docs/overview.txt.

* Fixed a typo in bin/delete_expired_users.py.

* Added French translation.

Version 0.3, 19 September 2007:

-------------------------------

Packaged from revision 89 in Subversion; download at

http://django-registration.googlecode.com/files/registration-0.3.tar.gz

* Changed ``register`` and ``activate`` views to accept

  ``template_name`` keyword argument for selecting a custom template.

* Changed ``register`` view to accept ``form_class`` keyword

  argument specifying the form to use.

* BACKWARDS-INCOMPATIBLE CHANGE: Changed

  ``RegistrationManager.create_inactive_user`` to use a template for

  the subject of the activation email.

* BACKWARDS-INCOMPATIBLE CHANGE: Removed the ``tos`` field from

  ``RegistrationForm``; if you were relying on it, switch to using

  ``RegistrationFormTermsOfService`` instead.

* BACKWARDS-INCOMPATIBLE CHANGE: The activation email template now

  receives the current ``Site`` object as the context variable

  ``site``, and the ``current_site`` variable, which only held the

  domain, is no longer available.

* Added script ``bin/delete_expired_users.py`` with instructions on

  how to use it as a cron job to clean up expired/inactive accounts.

* Marked strings for translation and added ``locale`` directory so

  that translations can be added.

* Updated to deal with merge of Django's Unicode branch into trunk;

  now using Unicode-aware functions everywhere.

Version 0.2, 29 May 2007:

-------------------------

Packaged from revision 76 in Subversion; download at

http://django-registration.googlecode.com/files/registration-0.2.tar.gz

* Added ability to specify a callback in

  ``RegistrationManager.create_inactive_user`` or in the ``register``

  view to enable creation of site-specific user profile.

* Separated out the logic of creating the profile into a new method on

  ``RegistrationManager``: ``create_profile``.

* Added URLConf support for various useful views in

  ``django.contrib.auth``.

* BACKWARDS-INCOMPATIBLE CHANGE: removed the ``key_generated`` field

  from ``RegistrationProfile``; activation key expiration is now

  calculated based on the ``date_joined`` field in the ``User`` model.

  Drop the ``key_generated`` column from your database when upgrading

  from 0.1.

Version 0.1, 23 May 2007:

-------------------------

Packaged from revision 56 in Subversion; download at

http://django-registration.googlecode.com/files/registration-0.1.tar.gz

* First packaged version using distutils.

* Added docs/ directory and overview.

Copyright (c) 2007-2012, James Bennett

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are

met:

    * Redistributions of source code must retain the above copyright

      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above

      copyright notice, this list of conditions and the following

      disclaimer in the documentation and/or other materials provided

      with the distribution.

    * Neither the name of the author nor the names of other

      contributors may be used to endorse or promote products derived

      from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR

A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT

OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT

LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

include CHANGELOG

include INSTALL

include LICENSE

include MANIFEST.in

include README.rst

include AUTHORS

recursive-include docs *

prune docs/_build

recursive-include registration/locale *

recursive-include registration/templates *

Metadata-Version: 1.1

Name: django-registration-redux

Version: 1.4

Summary: An extensible user-registration application for Django

Home-page: https://github.com/macropin/django-registration

Author: Andrew Cutler

Author-email: macropin@gmail.com

License: UNKNOWN

Description: .. -*-restructuredtext-*-

        :Description: Django-registration provides user registration functionality for Django websites.

        :maintainers: Macropin_ & Dicato_

        :contributors: `list of contributors <https://github.com/macropin/django-registration/graphs/contributors>`_

        .. _Macropin: https://github.com/macropin

        .. _Dicato: https://github.com/dicato

        .. image:: https://travis-ci.org/macropin/django-registration.svg?branch=master

            :target: https://travis-ci.org/macropin/django-registration

        .. image:: https://coveralls.io/repos/macropin/django-registration/badge.svg?branch=master

            :target: https://coveralls.io/r/macropin/django-registration/

        .. image:: https://badge.fury.io/py/django-registration-redux.svg

            :target: https://pypi.python.org/pypi/django-registration-redux/

        .. image:: https://pypip.in/download/django-registration-redux/badge.svg

            :target: https://pypi.python.org/pypi/django-registration-redux/

        If you have issues with the "django-registration-redux" package then please `raise them here`_.

        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

        other dependencies.

        For instructions on how to use this application, and on

        what it provides, see the file "quickstart.rst" in the "docs/"

        directory. Full documentation is also `available online`_

        Installation

        ------------

        Install, upgrade and uninstall django-registration-redux with these commands::

            pip install django-registration-redux

            pip install --upgrade django-registration-redux

            pip uninstall django-registration-redux

        To install it manually, run the following command inside this source directory::

            python setup.py install

        Or if you'd prefer you can simply place the included ``registration``

        directory somewhere on your Python path, or symlink to it from

        somewhere on your Python path; this is useful if you're working from a

        Git checkout.

        Note that this application requires Python 2.7/3.4 or later, and a

        functional installation of Django 1.7 or newer.

        Getting started with development

        ------------

        To get started with development, first install the required packages::

            make installdeps

        For convenience a ``Makefile`` is included which wraps the Python `invoke

        <http://www.pyinvoke.org/>`_ library. Once you work on a patch, you can test

        the functionality by running::

            make test

        Or equivalently::

            invoke test

        Command line arguments can be passed to the ``invoke`` script through the

        ``Makefile`` via the ``ARGS`` parameter. For example::

            make build ARGS=--docs

        Or equivalently::

            invoke build --docs

        Alternatives

        ------------

        `djangopackages.com <https://www.djangopackages.com/grids/g/registration/>`_

        has a comprehensive comparison of Django packages used for user registration

        and authentication.

        For example, `django-allauth <http://www.intenct.nl/projects/django-allauth/>`_

        is an alternative to django-regisitration-redux that provides user registration

        in addition to social authentication and email address management.

        License

        -------

        Django-registration-redux is licensed under `BSD License`.

        .. _`available online`: https://django-registration-redux.readthedocs.org/

        .. _`raise them here`: https://github.com/macropin/django-registration/issues

Platform: UNKNOWN

Classifier: Development Status :: 5 - Production/Stable

Classifier: Environment :: Web Environment

Classifier: Framework :: Django

Classifier: Intended Audience :: Developers

Classifier: License :: OSI Approved :: BSD License

Classifier: Operating System :: OS Independent

Classifier: Programming Language :: Python

Classifier: Programming Language :: Python :: 2.7

Classifier: Programming Language :: Python :: 3

Classifier: Programming Language :: Python :: 3.4

Classifier: Programming Language :: Python :: 3.5

Classifier: Topic :: Software Development :: Libraries :: Python Modules

Classifier: Topic :: Utilities

.. -*-restructuredtext-*-

:Description: Django-registration provides user registration functionality for Django websites.

:maintainers: Macropin_ & Dicato_

:contributors: `list of contributors <https://github.com/macropin/django-registration/graphs/contributors>`_

.. _Macropin: https://github.com/macropin

.. _Dicato: https://github.com/dicato

.. image:: https://travis-ci.org/macropin/django-registration.svg?branch=master

    :target: https://travis-ci.org/macropin/django-registration

.. image:: https://coveralls.io/repos/macropin/django-registration/badge.svg?branch=master

    :target: https://coveralls.io/r/macropin/django-registration/

.. image:: https://badge.fury.io/py/django-registration-redux.svg

    :target: https://pypi.python.org/pypi/django-registration-redux/

.. image:: https://pypip.in/download/django-registration-redux/badge.svg

    :target: https://pypi.python.org/pypi/django-registration-redux/

If you have issues with the "django-registration-redux" package then please `raise them here`_.

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

other dependencies.

For instructions on how to use this application, and on

what it provides, see the file "quickstart.rst" in the "docs/"

directory. Full documentation is also `available online`_

Installation

------------

Install, upgrade and uninstall django-registration-redux with these commands::

    pip install django-registration-redux

    pip install --upgrade django-registration-redux

    pip uninstall django-registration-redux

To install it manually, run the following command inside this source directory::

    python setup.py install

Or if you'd prefer you can simply place the included ``registration``

directory somewhere on your Python path, or symlink to it from

somewhere on your Python path; this is useful if you're working from a

Git checkout.

Note that this application requires Python 2.7/3.4 or later, and a

functional installation of Django 1.7 or newer.

Getting started with development

------------

To get started with development, first install the required packages::

    make installdeps

For convenience a ``Makefile`` is included which wraps the Python `invoke

<http://www.pyinvoke.org/>`_ library. Once you work on a patch, you can test

the functionality by running::

    make test

Or equivalently::

    invoke test

Command line arguments can be passed to the ``invoke`` script through the

``Makefile`` via the ``ARGS`` parameter. For example::

    make build ARGS=--docs

Or equivalently::

    invoke build --docs

Alternatives

------------

`djangopackages.com <https://www.djangopackages.com/grids/g/registration/>`_

has a comprehensive comparison of Django packages used for user registration

and authentication.

For example, `django-allauth <http://www.intenct.nl/projects/django-allauth/>`_

is an alternative to django-regisitration-redux that provides user registration

in addition to social authentication and email address management.

License

-------

Django-registration-redux is licensed under `BSD License`.

.. _`available online`: https://django-registration-redux.readthedocs.org/

.. _`raise them here`: https://github.com/macropin/django-registration/issues

Metadata-Version: 1.1

Name: django-registration-redux

Version: 1.4

Summary: An extensible user-registration application for Django

Home-page: https://github.com/macropin/django-registration

Author: Andrew Cutler

Author-email: macropin@gmail.com

License: UNKNOWN

Description: .. -*-restructuredtext-*-

        :Description: Django-registration provides user registration functionality for Django websites.

        :maintainers: Macropin_ & Dicato_

        :contributors: `list of contributors <https://github.com/macropin/django-registration/graphs/contributors>`_

        .. _Macropin: https://github.com/macropin

        .. _Dicato: https://github.com/dicato

        .. image:: https://travis-ci.org/macropin/django-registration.svg?branch=master

            :target: https://travis-ci.org/macropin/django-registration

        .. image:: https://coveralls.io/repos/macropin/django-registration/badge.svg?branch=master

            :target: https://coveralls.io/r/macropin/django-registration/

        .. image:: https://badge.fury.io/py/django-registration-redux.svg

            :target: https://pypi.python.org/pypi/django-registration-redux/

        .. image:: https://pypip.in/download/django-registration-redux/badge.svg

            :target: https://pypi.python.org/pypi/django-registration-redux/

        If you have issues with the "django-registration-redux" package then please `raise them here`_.

        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

        other dependencies.

        For instructions on how to use this application, and on

        what it provides, see the file "quickstart.rst" in the "docs/"

        directory. Full documentation is also `available online`_

        Installation

        ------------

        Install, upgrade and uninstall django-registration-redux with these commands::

            pip install django-registration-redux

            pip install --upgrade django-registration-redux

            pip uninstall django-registration-redux

        To install it manually, run the following command inside this source directory::

            python setup.py install

        Or if you'd prefer you can simply place the included ``registration``

        directory somewhere on your Python path, or symlink to it from

        somewhere on your Python path; this is useful if you're working from a

        Git checkout.

        Note that this application requires Python 2.7/3.4 or later, and a

        functional installation of Django 1.7 or newer.

        Getting started with development

        ------------

        To get started with development, first install the required packages::

            make installdeps

        For convenience a ``Makefile`` is included which wraps the Python `invoke

        <http://www.pyinvoke.org/>`_ library. Once you work on a patch, you can test

        the functionality by running::

            make test

        Or equivalently::

            invoke test

        Command line arguments can be passed to the ``invoke`` script through the

        ``Makefile`` via the ``ARGS`` parameter. For example::

            make build ARGS=--docs

        Or equivalently::

            invoke build --docs

        Alternatives

        ------------

        `djangopackages.com <https://www.djangopackages.com/grids/g/registration/>`_

        has a comprehensive comparison of Django packages used for user registration

        and authentication.

        For example, `django-allauth <http://www.intenct.nl/projects/django-allauth/>`_

        is an alternative to django-regisitration-redux that provides user registration

        in addition to social authentication and email address management.

        License

        -------

        Django-registration-redux is licensed under `BSD License`.

        .. _`available online`: https://django-registration-redux.readthedocs.org/

        .. _`raise them here`: https://github.com/macropin/django-registration/issues

Platform: UNKNOWN

Classifier: Development Status :: 5 - Production/Stable

Classifier: Environment :: Web Environment

Classifier: Framework :: Django

Classifier: Intended Audience :: Developers

Classifier: License :: OSI Approved :: BSD License

Classifier: Operating System :: OS Independent

Classifier: Programming Language :: Python

Classifier: Programming Language :: Python :: 2.7

Classifier: Programming Language :: Python :: 3

Classifier: Programming Language :: Python :: 3.4

Classifier: Programming Language :: Python :: 3.5

Classifier: Topic :: Software Development :: Libraries :: Python Modules

Classifier: Topic :: Utilities

AUTHORS

CHANGELOG

LICENSE

MANIFEST.in

README.rst

setup.cfg

setup.py

django_registration_redux.egg-info/PKG-INFO

django_registration_redux.egg-info/SOURCES.txt

django_registration_redux.egg-info/dependency_links.txt

django_registration_redux.egg-info/top_level.txt

docs/Makefile

docs/conf.py

docs/default-backend.rst

docs/faq.rst

docs/forms.rst

docs/index.rst

docs/make.bat

docs/quickstart.rst

docs/release-notes.rst

docs/signals.rst

docs/simple-backend.rst

docs/upgrade.rst

docs/views.rst

registration/__init__.py

registration/admin.py

registration/auth_urls.py

registration/forms.py

registration/models.py

registration/signals.py

registration/urls.py

registration/users.py

registration/views.py

registration/backends/__init__.py

registration/backends/default/__init__.py

registration/backends/default/urls.py

registration/backends/default/views.py

registration/backends/simple/__init__.py

registration/backends/simple/urls.py

registration/backends/simple/views.py

registration/locale/ar/LC_MESSAGES/django.mo

registration/locale/ar/LC_MESSAGES/django.po

registration/locale/bg/LC_MESSAGES/django.mo

registration/locale/bg/LC_MESSAGES/django.po

registration/locale/ca/LC_MESSAGES/django.mo

registration/locale/ca/LC_MESSAGES/django.po

registration/locale/cs/LC_MESSAGES/django.mo

registration/locale/cs/LC_MESSAGES/django.po

registration/locale/da/LC_MESSAGES/django.mo

registration/locale/da/LC_MESSAGES/django.po

registration/locale/de/LC_MESSAGES/django.mo

registration/locale/de/LC_MESSAGES/django.po

registration/locale/el/LC_MESSAGES/django.mo

registration/locale/el/LC_MESSAGES/django.po

registration/locale/en/LC_MESSAGES/django.mo

registration/locale/en/LC_MESSAGES/django.po

registration/locale/es/LC_MESSAGES/django.mo

registration/locale/es/LC_MESSAGES/django.po

registration/locale/es_AR/LC_MESSAGES/django.mo

registration/locale/es_AR/LC_MESSAGES/django.po

registration/locale/fa/LC_MESSAGES/django.mo

registration/locale/fa/LC_MESSAGES/django.po

registration/locale/fr/LC_MESSAGES/django.mo

registration/locale/fr/LC_MESSAGES/django.po

registration/locale/he/LC_MESSAGES/django.mo

registration/locale/he/LC_MESSAGES/django.po

registration/locale/hr/LC_MESSAGES/django.mo

registration/locale/hr/LC_MESSAGES/django.po

registration/locale/hu/LC_MESSAGES/django.mo

registration/locale/hu/LC_MESSAGES/django.po

registration/locale/is/LC_MESSAGES/django.mo

registration/locale/is/LC_MESSAGES/django.po

registration/locale/it/LC_MESSAGES/django.mo

registration/locale/it/LC_MESSAGES/django.po

registration/locale/ja/LC_MESSAGES/django.mo

registration/locale/ja/LC_MESSAGES/django.po

registration/locale/ko/LC_MESSAGES/django.mo

registration/locale/ko/LC_MESSAGES/django.po

registration/locale/nb/LC_MESSAGES/django.mo

registration/locale/nb/LC_MESSAGES/django.po

registration/locale/nl/LC_MESSAGES/django.mo

registration/locale/nl/LC_MESSAGES/django.po

registration/locale/pl/LC_MESSAGES/django.mo

registration/locale/pl/LC_MESSAGES/django.po

registration/locale/pt/LC_MESSAGES/django.mo

registration/locale/pt/LC_MESSAGES/django.po

registration/locale/pt_BR/LC_MESSAGES/django.mo

registration/locale/pt_BR/LC_MESSAGES/django.po

registration/locale/ru/LC_MESSAGES/django.mo

registration/locale/ru/LC_MESSAGES/django.po

registration/locale/sl/LC_MESSAGES/django.mo

registration/locale/sl/LC_MESSAGES/django.po

registration/locale/sr/LC_MESSAGES/django.mo

registration/locale/sr/LC_MESSAGES/django.po

registration/locale/sv/LC_MESSAGES/django.mo

registration/locale/sv/LC_MESSAGES/django.po

registration/locale/th/LC_MESSAGES/django.po

registration/locale/tr_TR/LC_MESSAGES/django.mo

registration/locale/tr_TR/LC_MESSAGES/django.po

registration/locale/zh_CN/LC_MESSAGES/django.mo

registration/locale/zh_CN/LC_MESSAGES/django.po

registration/locale/zh_TW/LC_MESSAGES/django.mo

registration/locale/zh_TW/LC_MESSAGES/django.po

registration/management/__init__.py

registration/management/commands/__init__.py

registration/management/commands/cleanupregistration.py

registration/migrations/0001_initial.py

registration/migrations/0002_registrationprofile_activated.py

registration/migrations/0003_migrate_activatedstatus.py

registration/migrations/__init__.py

registration/templates/registration/activate.html

registration/templates/registration/activation_complete.html

registration/templates/registration/activation_email.html

registration/templates/registration/activation_email.txt

registration/templates/registration/activation_email_subject.txt

registration/templates/registration/login.html

registration/templates/registration/logout.html

registration/templates/registration/password_change_done.html

registration/templates/registration/password_change_form.html

registration/templates/registration/password_reset_complete.html

registration/templates/registration/password_reset_confirm.html

registration/templates/registration/password_reset_done.html

registration/templates/registration/password_reset_email.html

registration/templates/registration/password_reset_form.html

registration/templates/registration/registration_base.html

registration/templates/registration/registration_closed.html

registration/templates/registration/registration_complete.html

registration/templates/registration/registration_form.html

registration/tests/__init__.py

registration/tests/admin_actions.py

registration/tests/default_backend.py

registration/tests/forms.py

registration/tests/forms_custom_user.py

registration/tests/models.py

registration/tests/simple_backend.py

registration/tests/urls.py

test_app/__init__.py

test_app/models.py

test_app/settings.py

test_app/settings_test.py

test_app/urls_default.py

test_app/urls_simple.py

registration

test_app

# Makefile for Sphinx documentation

#

# You can set these variables from the command line.

SPHINXOPTS    =

SPHINXBUILD   = sphinx-build

PAPER         =

# Internal variables.

PAPEROPT_a4     = -D latex_paper_size=a4

PAPEROPT_letter = -D latex_paper_size=letter

ALLSPHINXOPTS   = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .

.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest

help:

	@echo "Please use \`make <target>' where <target> is one of"

	@echo "  html      to make standalone HTML files"

	@echo "  dirhtml   to make HTML files named index.html in directories"

	@echo "  pickle    to make pickle files"

	@echo "  json      to make JSON files"

	@echo "  htmlhelp  to make HTML files and a HTML help project"

	@echo "  qthelp    to make HTML files and a qthelp project"

	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"

	@echo "  changes   to make an overview of all changed/added/deprecated items"

	@echo "  linkcheck to check all external links for integrity"

	@echo "  doctest   to run all doctests embedded in the documentation (if enabled)"

clean:

	-rm -rf _build/*

html:

	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html

	@echo

	@echo "Build finished. The HTML pages are in _build/html."

dirhtml:

	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) _build/dirhtml

	@echo

	@echo "Build finished. The HTML pages are in _build/dirhtml."

pickle:

	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle

	@echo

	@echo "Build finished; now you can process the pickle files."

json:

	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) _build/json

	@echo

	@echo "Build finished; now you can process the JSON files."

htmlhelp:

	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp

	@echo

	@echo "Build finished; now you can run HTML Help Workshop with the" \

	      ".hhp project file in _build/htmlhelp."

qthelp:

	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) _build/qthelp

	@echo

	@echo "Build finished; now you can run "qcollectiongenerator" with the" \

	      ".qhcp project file in _build/qthelp, like this:"

	@echo "# qcollectiongenerator _build/qthelp/django-registration.qhcp"

	@echo "To view the help file:"

	@echo "# assistant -collectionFile _build/qthelp/django-registration.qhc"

latex:

	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex

	@echo

	@echo "Build finished; the LaTeX files are in _build/latex."

	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \

	      "run these through (pdf)latex."

changes:

	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes

	@echo

	@echo "The overview file is in _build/changes."

linkcheck:

	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck

	@echo

	@echo "Link check complete; look for any errors in the above output " \

	      "or in _build/linkcheck/output.txt."

doctest:

	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) _build/doctest

	@echo "Testing of doctests in the sources finished, look at the " \

	      "results in _build/doctest/output.txt."

# -*- coding: utf-8 -*-

#

# django-registration documentation build configuration file, created by

# sphinx-quickstart on Mon Jun 22 02:57:42 2009.

#

# This file is execfile()d with the current directory set to its containing dir.

#

# Note that not all possible configuration values are present in this

# autogenerated file.

#

# All configuration values have a default; values that are commented out

# serve to show the default.

import sys, os

# If extensions (or modules to document with autodoc) are in another directory,

# add these directories to sys.path here. If the directory is relative to the

# documentation root, use os.path.abspath to make it absolute, like shown here.

#sys.path.append(os.path.abspath('.'))

# -- General configuration -----------------------------------------------------

# Add any Sphinx extension module names here, as strings. They can be extensions

# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.

extensions = []

# Add any paths that contain templates here, relative to this directory.

templates_path = ['_templates']

# The suffix of source filenames.

source_suffix = '.rst'

# The encoding of source files.

#source_encoding = 'utf-8'

# The master toctree document.

master_doc = 'index'

# General information about the project.

project = u'django-registration-redux'

copyright = u'2007-2013, James Bennett. 2014, Andrew Cutler and others.'

# The version info for the project you're documenting, acts as replacement for

# |version| and |release|, also used in various other places throughout the

# built documents.

#

# The short X.Y version.

version = '1.4'

# The full version, including alpha/beta/rc tags.

release = '1.4'

# The language for content autogenerated by Sphinx. Refer to documentation

# for a list of supported languages.

#language = None

# There are two options for replacing |today|: either, you set today to some

# non-false value, then it is used:

#today = ''

# Else, today_fmt is used as the format for a strftime call.

#today_fmt = '%B %d, %Y'

# List of documents that shouldn't be included in the build.

#unused_docs = []

# List of directories, relative to source directory, that shouldn't be searched

# for source files.

exclude_trees = ['_build']

# The reST default role (used for this markup: `text`) to use for all documents.

#default_role = None

# If true, '()' will be appended to :func: etc. cross-reference text.

#add_function_parentheses = True

# If true, the current module name will be prepended to all description

# unit titles (such as .. function::).

#add_module_names = True

# If true, sectionauthor and moduleauthor directives will be shown in the

# output. They are ignored by default.

#show_authors = False

# The name of the Pygments (syntax highlighting) style to use.

pygments_style = 'sphinx'

# A list of ignored prefixes for module index sorting.

#modindex_common_prefix = []

# -- Options for HTML output ---------------------------------------------------

# The theme to use for HTML and HTML Help pages.  Major themes that come with

# Sphinx are currently 'default' and 'sphinxdoc'.

html_theme = 'default'

# Theme options are theme-specific and customize the look and feel of a theme

# further.  For a list of options available for each theme, see the

# documentation.

#html_theme_options = {}

# Add any paths that contain custom themes here, relative to this directory.

#html_theme_path = []

# The name for this set of Sphinx documents.  If None, it defaults to

# "<project> v<release> documentation".

#html_title = None

# A shorter title for the navigation bar.  Default is the same as html_title.

#html_short_title = None

# The name of an image file (relative to this directory) to place at the top

# of the sidebar.

#html_logo = None

# The name of an image file (within the static path) to use as favicon of the

# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32

# pixels large.

#html_favicon = None

# Add any paths that contain custom static files (such as style sheets) here,

# relative to this directory. They are copied after the builtin static files,

# so a file named "default.css" will overwrite the builtin "default.css".

#html_static_path = ['_static']

# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,

# using the given strftime format.

#html_last_updated_fmt = '%b %d, %Y'

# If true, SmartyPants will be used to convert quotes and dashes to

# typographically correct entities.

#html_use_smartypants = True

# Custom sidebar templates, maps document names to template names.

#html_sidebars = {}

# Additional templates that should be rendered to pages, maps page names to

# template names.

#html_additional_pages = {}

# If false, no module index is generated.

#html_use_modindex = True

# If false, no index is generated.

#html_use_index = True

# If true, the index is split into individual pages for each letter.

#html_split_index = False

# If true, links to the reST sources are added to the pages.

#html_show_sourcelink = True

# If true, an OpenSearch description file will be output, and all pages will

# contain a <link> tag referring to it.  The value of this option must be the

# base URL from which the finished HTML is served.

#html_use_opensearch = ''

# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").

#html_file_suffix = ''

# Output file base name for HTML help builder.

htmlhelp_basename = 'django-registration-reduxdoc'

# -- Options for LaTeX output --------------------------------------------------

# The paper size ('letter' or 'a4').

#latex_paper_size = 'letter'

# The font size ('10pt', '11pt' or '12pt').

#latex_font_size = '10pt'

# Grouping the document tree into LaTeX files. List of tuples

# (source start file, target name, title, author, documentclass [howto/manual]).

latex_documents = [

  ('index', 'django-registration-redux.tex', u'django-registration-redux Documentation',

   u'James Bennett', 'manual'),

]

# The name of an image file (relative to this directory) to place at the top of

# the title page.

#latex_logo = None

# For "manual" documents, if this is true, then toplevel headings are parts,

# not chapters.

#latex_use_parts = False

# Additional stuff for the LaTeX preamble.

#latex_preamble = ''

# Documents to append as an appendix to all manuals.

#latex_appendices = []

# If false, no module index is generated.

#latex_use_modindex = True

rst_epilog = '.. |project| replace:: %s' % project

.. _default-backend:

.. module:: registration.backends.default

The default backend

===================

A default registration backend` is bundled with |project|,

as the module ``registration.backends.default``, and implements a

simple two-step workflow in which a new user first registers, then

confirms and activates the new account by following a link sent to the

email address supplied during registration.

Default behavior and configuration

----------------------------------

To make use of this backend, simply include the URLConf

``registration.backends.default.urls`` at whatever location you choose

in your URL hierarchy.

This backend makes use of the following settings:

``ACCOUNT_ACTIVATION_DAYS``

    This is the number of days users will have to activate their

    accounts after registering. Failing to activate during that period

    will leave the account inactive (and possibly subject to

    deletion). This setting is required, and must be an integer.

``REGISTRATION_OPEN``

    A boolean (either ``True`` or ``False``) indicating whether

    registration of new accounts is currently permitted. This setting

    is optional, and a default of ``True`` will be assumed if it is

    not supplied.

``INCLUDE_AUTH_URLS``

    A boolean (either ``True`` or ``False``) indicating whether auth urls

    (mapped to ``django.contrib.auth.views``) should be included in the

    ``urlpatterns`` of the application backend.

``INCLUDE_REGISTER_URL``

    A boolean (either ``True`` or ``False``) indicating whether the view

    for registering accounts should be included in the ``urlpatterns``

    of the application backend.

``REGISTRATION_FORM``

    A string dotted path to the desired registration form.

By default, this backend uses

:class:`registration.forms.RegistrationForm` as its form class for

user registration; this can be overridden by passing the keyword

argument ``form_class`` to the :func:`~registration.views.register`

view.

Two views are provided:

``registration.backends.default.views.RegistrationView`` and

``registration.backends.default.views.ActivationView``. These views

subclass |project|'s base

:class:`~registration.views.RegistrationView` and

:class:`~registration.views.ActivationView`, respectively, and

implement the two-step registration/activation process.

Upon successful registration -- not activation -- the default redirect

is to the URL pattern named ``registration_complete``; this can be

overridden in subclasses by changing

:attr:`~registration.views.RegistrationView.success_url` or

implementing

:meth:`~registration.views.RegistrationView.get_success_url()`

Upon successful activation, the default redirect is to the URL pattern

named ``registration_activation_complete``; this can be overridden in

subclasses by implementing

:meth:`~registration.views.ActivationView.get_success_url()`.

How account data is stored for activation

-----------------------------------------

During registration, a new instance of

``django.contrib.auth.models.User`` is created to represent the new

account, with the ``is_active`` field set to ``False``. An email is

then sent to the email address of the account, containing a link the

user must click to activate the account; at that point the

``is_active`` field is set to ``True``, and the user may log in

normally.

Activation is handled by generating and storing an activation key in

the database, using the following model:

.. currentmodule:: registration.models

.. class:: RegistrationProfile

   A simple representation of the information needed to activate a new

   user account. This is **not** a user profile; it simply provides a

   place to temporarily store the activation key and determine whether

   a given account has been activated.

   Has the following fields:

   .. attribute:: user

      A ``ForeignKey`` to ``django.contrib.auth.models.User``,

      representing the user account for which activation information

      is being stored.

   .. attribute:: activation_key

      A 40-character ``CharField``, storing the activation key for the

      account. The activation key is the hexdigest of a SHA1 hash.

   .. attribute:: activated

      A ``BooleanField``, storing whether or not the the User has activated

      their account. Storing this independent from ``self.user.is_active``

      allows accounts to be deactivated and prevent being reactivated without

      authorization.

   And the following methods:

   .. method:: activation_key_expired()

      Determines whether this account's activation key has expired,

      and returns a boolean (``True`` if expired, ``False``

      otherwise). Uses the following algorithm:

      1. If :attr:`activated` is ``True``, the account

         has already been activated and so the key is considered to

         have expired.

      2. Otherwise, the date of registration (obtained from the

         ``date_joined`` field of :attr:`user`) is compared to the

         current date; if the span between them is greater than the

         value of the setting ``ACCOUNT_ACTIVATION_DAYS``, the key is

         considered to have expired.

      :rtype: bool

   .. method:: send_activation_email(site[, request])

      Sends an activation email to the address of the account.

      The activation email will make use of two templates:

      ``registration/activation_email_subject.txt`` and

      ``registration/activation_email.txt``, which are used for the

      subject of the email and the body of the email,

      respectively. Each will receive the following context:

      ``activation_key``

          The value of :attr:`activation_key`.

      ``expiration_days``

          The number of days the user has to activate, taken from the

          setting ``ACCOUNT_ACTIVATION_DAYS``.

      ``site``

          An object representing the site on which the account was

          registered; depending on whether ``django.contrib.sites`` is

          installed, this may be an instance of either

          ``django.contrib.sites.models.Site`` (if the sites

          application is installed) or

          ``django.contrib.sites.models.RequestSite`` (if

          not). Consult `the documentation for the Django sites

          framework

          <http://docs.djangoproject.com/en/dev/ref/contrib/sites/>`_

          for details regarding these objects' interfaces.

      ``request``

          Django's ``HttpRequest`` object for better flexibility.

          When provided, it will also provide all the data via

          installed template context processors which can provide

          even more flexibility by using many Django's provided

          and custom template context processors to provide more

          variables to the template.

      Because email subjects must be a single line of text, the

      rendered output of ``registration/activation_email_subject.txt``

      will be forcibly condensed to a single line.

      :param site: An object representing the site on which account

         was registered.

      :type site: ``django.contrib.sites.models.Site`` or

        ``django.contrib.sites.models.RequestSite``

      :param request: Optional Django's ``HttpRequest`` object

         from view which if supplied will be passed to the template

         via ``RequestContext``. As a consequence, all installed

         ``TEMPLATE_CONTEXT_PROCESSORS`` will be used to populate

         context.

      :type request: ``django.http.request.HttpRequest``

      :rtype: ``None``

Additionally, :class:`RegistrationProfile` has a custom manager

(accessed as ``RegistrationProfile.objects``):

.. class:: RegistrationManager

   This manager provides several convenience methods for creating and

   working with instances of :class:`RegistrationProfile`:

   .. method:: activate_user(activation_key)

      Validates ``activation_key`` and, if valid, activates the

      associated account by setting its ``is_active`` field to

      ``True``. To prevent re-activation of accounts, the

      :attr:`~RegistrationProfile.activated` of the

      :class:`RegistrationProfile` for the account will be set to

      ``True`` after successful activation.

      Returns the ``User`` instance representing the account if

      activation is successful, ``False`` otherwise.

      :param activation_key: The activation key to use for the

         activation.

      :type activation_key: string, a 40-character SHA1 hexdigest

      :rtype: ``User`` or bool

   .. method:: delete_expired_users

      Removes expired instances of :class:`RegistrationProfile`, and

      their associated user accounts, from the database. This is

      useful as a periodic maintenance task to clean out accounts

      which registered but never activated.

      Accounts to be deleted are identified by searching for instances

      of :class:`RegistrationProfile` with expired activation keys and

      with associated user accounts which are inactive (have their

      ``is_active`` field set to ``False``). To disable a user account

      without having it deleted, simply delete its associated

      :class:`RegistrationProfile`; any ``User`` which does not have

      an associated :class:`RegistrationProfile` will not be deleted.

      A custom management command is provided which will execute this

      method, suitable for use in cron jobs or other scheduled

      maintenance tasks: ``manage.py cleanupregistration``.

      :rtype: ``None``

   .. method:: create_inactive_user(site, [new_user=None, send_email=True, request=None, **user_info])

      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 new_user: The user instance.

      :type new_user: ``django.contrib.auth.models.AbstractBaseUser```

      :param user_info: The fields to use for the new account.

      :type user_info: dict

      :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

         :meth:`RegistrationProfile.send_activation_email`). If

         ``False``, no email will be sent (but the account will still

         be inactive)

      :type send_email: bool

      :param request: If ``send_email`` parameter is ``True``

         and if ``request`` is supplied, it will be passed to the

         email templates for better flexibility.

         Please take a look at the sample email templates

         for better explanation how it can be used.

      :type request: ``django.http.request.HttpRequest``

      :rtype: ``User``

   .. method:: create_profile(user)

      Creates and returns a :class:`RegistrationProfile` instance for

      the account represented by ``user``.

      The ``RegistrationProfile`` created by this method will have its

      :attr:`~RegistrationProfile.activation_key` set to a SHA1 hash

      generated from a combination of the account's username and a

      random salt.

      :param user: The user account; an instance of

         ``django.contrib.auth.models.User``.

      :type user: ``User``

      :rtype: ``RegistrationProfile``

.. _faq:

Frequently-asked questions

==========================

The following are miscellaneous common questions and answers related

to installing/using |project|, culled from bug reports,

emails and other sources.

General

-------

**What license is django-registration-redux under?**

    |project| is offered under a three-clause BSD-style

    license; this is `an OSI-approved open-source license

    <http://www.opensource.org/licenses/bsd-license.php>`_, and allows

    you a large degree of freedom in modifiying and redistributing the

    code. For the full terms, see the file ``LICENSE`` which came with

    your copy of |project|; if you did not receive a copy of

    this file, you can `view it online

    <https://github.com/macropin/django-registration/blob/master/LICENSE>`_.

**Why are the forms and models for the default backend not in the default backend?**

    The model and manager used by :ref:`the default backend

    <default-backend>` are in ``registration.models``, and the default

    form class (and various subclasses) are in ``registration.forms``;

    logically, they might be expected to exist in

    ``registration.backends.default``, but there are several reasons

    why that's not such a good idea:

    1. Older versions of |project| made use of the model and

       form classes, and moving them would create an unnecessary

       backwards incompatibility: ``import`` statements would need to

       be changed, and some database updates would be needed to

       reflect the new location of the

       :class:`~registration.models.RegistrationProfile` model.

    2. Due to the design of Django's ORM, the ``RegistrationProfile``

       model would end up with an ``app_label`` of ``default``, which

       isn't particularly descriptive and may conflict with other

       applications. By keeping it in ``registration.models``, it

       retains an ``app_label`` of ``registration``, which more

       accurately reflects what it does and is less likely to cause

       problems.

    3. Although the ``RegistrationProfile`` model and the various

       :ref:`form classes <forms>` are used by the default backend,

       they can and are meant to be reused as needed by other

       backends. Any backend which uses an activation step should feel

       free to reuse the ``RegistrationProfile`` model, for example,

       and the registration form classes are in no way tied to a

       specific backend (and cover a number of common use cases which

       will crop up regardless of the specific backend logic in use).

Installation and setup

----------------------

**How do I install django-registration-redux?**

    Full instructions are available in :ref:`the quick start guide <quickstart>`.

**Do I need to put a copy of django-registration-redux in every project I use it in?**

    No; putting applications in your project directory is a very bad

    habit, and you should stop doing it. If you followed the

    instructions mentioned above, |project| was installed

    into a location that's on your Python import path, so you'll only

    ever need to add ``registration`` to your ``INSTALLED_APPS``

    setting (in any project, or in any number of projects), and it

    will work.

Configuration

-------------

**Do I need to rewrite the views to change the way they behave?**

    Not always. Any behavior controlled by an attribute on a

    class-based view can be changed by passing a different value for

    that attribute in the URLConf. See `Django's class-based view

    documentation

    <https://docs.djangoproject.com/en/dev/topics/class-based-views/#simple-usage-in-your-urlconf>`_

    for examples of this.

    For more complex or fine-grained control, you will likely want to

    subclass :class:`~registration.views.RegistrationView` or

    :class:`~registration.views.ActivationView`, or both, add your

    custom logic to your subclasses, and then create a URLConf which

    makes use of your subclasses.

**I don't want to write my own URLconf because I don't want to write patterns for all the auth views!**

    You're in luck, then; |project| provides a URLconf which

    *only* contains the patterns for the auth views, and which you can

    include in your own URLconf anywhere you'd like; it lives at

    ``registration.auth_urls``.

**I don't like the names you've given to the URL patterns!**

    In that case, you should feel free to set up your own URLconf

    which uses the names you want.

Troubleshooting

---------------

**I've got functions listening for the registration/activation signals, but they're not getting called!**

    The most common cause of this is placing |project| in a

    sub-directory that's on your Python import path, rather than

    installing it directly onto the import path as normal. Importing

    from |project| in that case can cause various issues,

    including incorrectly connecting signal handlers. For example, if

    you were to place |project| inside a directory named

    ``django_apps``, and refer to it in that manner, you would end up

    with a situation where your code does this::

        from django_apps.registration.signals import user_registered

    But |project| will be doing::

        from registration.signals import user_registered

    From Python's point of view, these import statements refer to two

    different objects in two different modules, and so signal handlers

    connected to the signal from the first import will not be called

    when the signal is sent using the second import.

    To avoid this problem, follow the standard practice of installing

    |project| directly on your import path and always

    referring to it by its own module name: ``registration`` (and in

    general, it is always a good idea to follow normal Python

    practices for installing and using Django applications).

**I want to use custom templates, but django keeps using the admin templates instead of mine!**

    To fix this, make sure that in the ``INSTALLED_APPS`` of your

    ``settings.py`` the entry for the ``registration`` app is placed

    above ``django.contrib.admin``.

Tips and tricks

---------------

**How do I log a user in immediately after registration or activation?**

    Take a look at the implementation of :ref:`the simple backend

    <simple-backend>`, which logs a user in immediately after

    registration.

**How do I re-send an activation email?**

    Assuming you're using :ref:`the default backend

    <default-backend>`, a `custom admin action

    <http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/>`_

    is provided for this; in the admin for the

    :class:`~registration.models.RegistrationProfile` model, simply

    click the checkbox for the user(s) you'd like to re-send the email

    for, then select the "Re-send activation emails" action.

**How do I manually activate a user?**

    In the default backend, 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.

.. _forms:

.. module:: registration.forms

Forms for user registration

===========================

Several form classes are provided with |project|, covering

common cases for gathering account information and implementing common

constraints for user registration. These forms were designed with

|project|'s :ref:`default backend <default-backend>` in

mind, but may also be useful in other situations.

.. class:: RegistrationForm

   A simple form for registering an account. Has the following fields,

   all of which are required:

   ``username``

       The username to use for the new account. This is represented as

       a text input which validates that the username is unique,

       consists entirely of alphanumeric characters and underscores

       and is at most 30 characters in length.

   ``email``

      The email address to use for the new account. This is

      represented as a text input which accepts email addresses up to

      75 characters in length.

   ``password1``

      The password to use for the new account. This represented as a

      password input (``input type="password"`` in the rendered HTML).

   ``password2``

      The password to use for the new account. This represented as a

      password input (``input type="password"`` in the rendered HTML).

      Password mismatches are recorded as errors of ``password2``.

   The constraints on usernames and email addresses match those

   enforced by Django's default authentication backend for instances

   of ``django.contrib.auth.models.User``. The repeated entry of the

   password serves to catch typos.

.. class:: RegistrationFormTermsOfService

   A subclass of :class:`RegistrationForm` which adds one additional,

   required field:

   ``tos``

       A checkbox indicating agreement to the site's terms of

       service/user agreement.

.. class:: RegistrationFormUniqueEmail

   A subclass of :class:`RegistrationForm` which enforces uniqueness

   of email addresses in addition to uniqueness of usernames.

.. class:: RegistrationFormNoFreeEmail

   A subclass of :class:`RegistrationForm` which disallows

   registration using addresses from some common free email

   providers. This can, in some cases, cut down on automated

   registration by spambots.

   By default, the following domains are disallowed for email

   addresses:

   * ``aim.com``

   * ``aol.com``

   * ``email.com``

   * ``gmail.com``

   * ``googlemail.com``

   * ``hotmail.com``

   * ``hushmail.com``

   * ``msn.com``

   * ``mail.ru``

   * ``mailinator.com``

   * ``live.com``

   * ``yahoo.com``

   To change this, subclass this form and set the class attribute

   ``bad_domains`` to a list of domains you wish to disallow.

Multiple Form Inheritance

----------------

Multiple :class:`RegistrationForm` subclasses can be inherited into

one class.  For instance, if your project requires a terms of service 

and a unique email upon registration, those subclasses can be inherited 

into a single class.  That would look like this:

   class CustomForm(RegistrationFormTermsOfService, RegistrationFormUniqueEmail):

      pass

NOTE: If inheriting both :class:`RegistrationFormNoFreeEmail` and 

:class:`RegistrationFormUniqueEmail`.  :class:`RegistrationFormNoFreeEmail` must

be inherited first, like this:

   class CustomForm(RegistrationFormNoFreeEmail, RegistrationFormUniqueEmail):

      pass

.. django-registration-redux documentation master file, created by

   sphinx-quickstart on Mon Jun 22 02:57:42 2009.

   You can adapt this file completely to your liking, but it should at least

   contain the root `toctree` directive.

|project| |version| documentation

=================================

This documentation covers the |version| release of

|project|, a simple but extensible application providing

user registration functionality for `Django

<http://www.djangoproject.com>`_ powered websites.

Although nearly all aspects of the registration process are

customizable, out-of-the-box support is provided for two common use

cases:

* Two-phase registration, consisting of initial signup followed by a

  confirmation email with instructions for activating the new account.

* One-phase registration, where a user signs up and is immediately

  active and logged in.

To get up and running quickly, consult the :ref:`quick-start guide

<quickstart>`, which describes all the necessary steps to install

|project| and configure it for the default workflow. For

more detailed information, including how to customize the registration

process (and support for alternate registration systems), read through

the documentation listed below.

If you are upgrading from a previous release, please read the

:ref:`upgrade guide <upgrade>` for information on what's changed.

Contents:

.. toctree::

   :maxdepth: 1

   quickstart

   release-notes

   upgrade

   default-backend

   simple-backend

   forms

   views

   signals

   faq

.. seealso::

   * `Django's authentication documentation

     <http://docs.djangoproject.com/en/dev/topics/auth/>`_; Django's

     authentication system is used by |project|'s default

     configuration.

@ECHO OFF

REM Command file for Sphinx documentation

set SPHINXBUILD=sphinx-build

set ALLSPHINXOPTS=-d _build/doctrees %SPHINXOPTS% .

if NOT "%PAPER%" == "" (

	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%

)