django-registration-2.2/ 0000755 0000767 0000767 00000000000 13011716531 014543 5 ustar james 0000000 0000000 django-registration-2.2/AUTHORS 0000644 0000767 0000767 00000002066 12623771034 015626 0 ustar james 0000000 0000000 The primary author of django-registration is James Bennett, who may
be found online at .
Over the past eight years of django-registration's development,
however, many others have contributed code, documentation and
translations, and django-registration would not be what it is without
their help. Below is a list of contributors who can be identified from
the development history:
* Samuel Adam
* A. Al-Ibrahim
* Adam Alton
* Florian Apolloner
* Carles Barrobés
* Nico den Boer
* Rune Bromer
* Joost Cassee
* Flavio Curella
* Baptiste Darthenay
* Nebojsa Djordjevic
* Liang Feng
* Ilya Filippov
* Rapahel Hertzog
* Recep Kirmizi
* Domen Kožar
* Meir Kriheli
* Björn Kristinsson
* Panos Laganakos
* Nicola Larosa
* Jannis Leidel
* Jon Lønne
* João Luiz Lorencetti
* Italo Maia
* Mohsen Mansouryar
* Leonardo Manuel Rocha
* Nuno Mariz
* Andy Mikhailenko
* Vladislav Mitov
* Marko Mrdjenovic
* Michael Niewöhner
* Shinya Okano
* Young Gyu Park
* Duncan Parkes
* Patrick Samson
* Daniel Samuels
* Ernesto Rico Schmidt
* Emil Stenström
* Jarek Zgoda
django-registration-2.2/django_registration.egg-info/ 0000755 0000767 0000767 00000000000 13011716531 022271 5 ustar james 0000000 0000000 django-registration-2.2/django_registration.egg-info/dependency_links.txt 0000644 0000767 0000767 00000000001 13011716531 026337 0 ustar james 0000000 0000000
django-registration-2.2/django_registration.egg-info/not-zip-safe 0000644 0000767 0000767 00000000001 13011716531 024517 0 ustar james 0000000 0000000
django-registration-2.2/django_registration.egg-info/PKG-INFO 0000644 0000767 0000767 00000002226 13011716531 023370 0 ustar james 0000000 0000000 Metadata-Version: 1.1
Name: django-registration
Version: 2.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
Author-email: james@b-list.org
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Framework :: Django
Classifier: Framework :: Django :: 1.8
Classifier: Framework :: Django :: 1.9
Classifier: Framework :: Django :: 1.10
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Topic :: Software Development :: Libraries :: Python Modules
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.3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Topic :: Utilities
django-registration-2.2/django_registration.egg-info/SOURCES.txt 0000644 0000767 0000767 00000011711 13011716531 024156 0 ustar james 0000000 0000000 AUTHORS
LICENSE
MANIFEST.in
README.rst
setup.cfg
setup.py
django_registration.egg-info/PKG-INFO
django_registration.egg-info/SOURCES.txt
django_registration.egg-info/dependency_links.txt
django_registration.egg-info/not-zip-safe
django_registration.egg-info/top_level.txt
docs/Makefile
docs/conf.py
docs/custom-user.rst
docs/faq.rst
docs/forms.rst
docs/hmac.rst
docs/index.rst
docs/install.rst
docs/make.bat
docs/model-workflow.rst
docs/quickstart.rst
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
registration/auth_urls.py
registration/forms.py
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
registration/backends/default/urls.py
registration/backends/default/views.py
registration/backends/hmac/__init__.py
registration/backends/hmac/urls.py
registration/backends/hmac/views.py
registration/backends/model_activation/__init__.py
registration/backends/model_activation/urls.py
registration/backends/model_activation/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/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/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/__init__.py
registration/tests/__init__.py
registration/tests/base.py
registration/tests/test_forms.py
registration/tests/test_hmac_workflow.py
registration/tests/test_model_workflow.py
registration/tests/test_models.py
registration/tests/test_simple_workflow.py
registration/tests/test_views.py
registration/tests/urls.py
registration/tests/views.py
registration/tests/templates/registration/activate.html
registration/tests/templates/registration/activation_complete.html
registration/tests/templates/registration/activation_email.txt
registration/tests/templates/registration/activation_email_subject.txt
registration/tests/templates/registration/registration_closed.html
registration/tests/templates/registration/registration_complete.html
registration/tests/templates/registration/registration_form.html django-registration-2.2/django_registration.egg-info/top_level.txt 0000644 0000767 0000767 00000000015 13011716531 025017 0 ustar james 0000000 0000000 registration
django-registration-2.2/docs/ 0000755 0000767 0000767 00000000000 13011716531 015473 5 ustar james 0000000 0000000 django-registration-2.2/docs/conf.py 0000644 0000767 0000767 00000001237 13011716351 016775 0 ustar james 0000000 0000000 import os
on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
extensions = []
templates_path = ['_templates']
source_suffix = '.rst'
master_doc = 'index'
project = u'django-registration'
copyright = u'2007-2016, James Bennett'
version = '2.2'
release = '2.2'
exclude_trees = ['_build']
pygments_style = 'sphinx'
html_static_path = ['_static']
htmlhelp_basename = 'django-registrationdoc'
latex_documents = [
('index', 'django-registration.tex', u'django-registration Documentation',
u'James Bennett', 'manual'),
]
if not on_rtd:
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
django-registration-2.2/docs/custom-user.rst 0000644 0000767 0000767 00000013167 13007361516 020527 0 ustar james 0000000 0000000 .. _custom-user:
Custom user models
==================
When django-registration was first developed, Django's
authentication system supported only its own built-in user model,
``django.contrib.auth.models.User``. More recent versions of Django
have introduced support for `custom user models
`_.
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 `-
and :ref:`model `-based -- require that your user
model have the following fields:
* ``email`` -- a textual field (``EmailField``, ``CharField`` or
``TextField``) holding the user's 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 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.
The model-based activation workflow requires one additional field:
* ``date_joined`` -- a ``DateField`` or ``DateTimeField`` indicating
when the user's account was registered.
:ref:`The simple one-step workflow ` requires that
your user model set ``USERNAME_FIELD``, and requires that it define a
field named ``password`` for storing the user's password (it will
expect to find this value in the ``password1`` field of the
registration form); 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. django-registration-2.2/docs/faq.rst 0000644 0000767 0000767 00000022314 13007361607 017003 0 ustar james 0000000 0000000 .. _faq:
Frequently-asked questions
==========================
The following are miscellaneous common questions and answers related
to installing/using django-registration, culled from bug reports,
emails and other sources.
General
-------
**How can I support social-media and other auth schemes, like Facebook or GitHub?**
By using `django-allauth
`_. No single
application can or should provide a universal API for every
authentication system ever developed; django-registration
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 integration with third-party authentication services far
more effectively.
**What license is django-registration under?**
django-registration is offered under a three-clause BSD-style
license; this is `an OSI-approved open-source license
`_, 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 django-registration; if you did not receive a copy of
this file, you can view it online at
.
**What versions of Django and Python are supported?**
As of django-registration |version|, Django 1.8, 1.9, and 1.10
are supported, on Python 2.7, 3.3 (Django 1.8 only), 3.4 and
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 work
without modification on Python 3.6 once it is released.
**I found a bug or want to make an improvement!**
The canonical development repository for django-registration
is online at
. Issues and
pull requests can both be filed there.
If you'd like to contribute to django-registration, that's
great! Just please remember that pull requests should include
tests and documentation for any changes made, and that following
`PEP 8 `_ is
mandatory. Pull requests without documentation won't be merged,
and PEP 8 style violations or test coverage below 100% are both
configured to break the build.
**How secure is django-registration?**
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
deployment and server configuration, and there could always be
security issues that just haven't been recognized yet.
django-registration does, however, try to avoid common security
issues:
* django-registration |version| only supports versions of
Django which were receiving upstream security support at the time
of release.
* django-registration does not attempt to generate or store
passwords, and does not transmit credentials which could be used
to log in (the only "credential" ever sent out by
django-registration is an activation key used in the two-step
activation workflows, and that key can only be used to make an
account active; it cannot be used to log in).
* django-registration works with Django's own security features
(including cryptographic features) where possible, rather than
reinventing its own.
**How do I run the tests?**
django-registration makes use of Django's own built-in
unit-testing tools, and supports several ways to execute its test
suite:
* Within a Django project, simply invoke ``manage.py test
registration``.
* If you've installed django-registration (so that it's on
your Python import path) and Django, but don't yet have a
project created or want to test independently of a project, you
can run ``registration/runtests.py``, or you can invoke ``python
setup.py test`` (which will simply run
``registration/runtests.py``).
Additionally, the ``setup.cfg`` file included in
django-registration provides configuration for `coverage.py
`_, enabling
easy recording and reporting of test coverage.
Installation and setup
----------------------
**How do I install django-registration?**
Full instructions are available in :ref:`the installation guide
`. For configuration, see :ref:`the quick start guide
`.
**Does django-registration come with any sample templates I can use right away?**
No, for two reasons:
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
would probably end up working with none of them.
2. A number of things in django-registration depend on the
specific registration workflow you use, including the variables
which end up in template contexts. Since django-registration
has no way of knowing in advance what workflow you're going to
be using, it also has no way of knowing what your templates
will need to look like.
Fortunately, however, django-registration has good documentation
which explains what context variables will be available to
templates, and so it should be easy for anyone who knows Django's
template system to create templates which integrate with their own
site.
Configuration
-------------
**Should I used the model-based or HMAC activation workflow?**
You're free to choose whichever one you think best fits your
needs. However, :ref:`the model-based workflow `
is mostly provided for backwards compatibility with older versions
of django-registration; it dates to 2007, and though it is
still as functional as ever, :ref:`the HMAC workflow
` has less overhead (i.e., no need to install or
work with any models) due to being able to take advantage of more
modern features in Django.
**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
`_
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; django-registration 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.
**I'm using a custom user model; how do I make that work?**
See :ref:`the custom user documentation `.
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 one-step workflow
`, which logs a user in immediately after
registration.
**How do I re-send an activation email?**
Assuming you're using :ref:`the model-based workflow
`, a `custom admin action
`_
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 :ref:`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 the HMAC-based workflow, simply toggle the ``is_active`` field
of the user in the admin.
**How do I allow Unicode in usernames?**
Use Python 3. Django's username validation allows any word
character plus some additional characters, but the definition of
"word character" depends on the Python version in use. On Python
2, only ASCII will be permitted; on Python 3, usernames containing
word characters matched by a regex with the ``UNICODE`` flag will
be accepted.
django-registration-2.2/docs/forms.rst 0000644 0000767 0000767 00000007736 13007361505 017372 0 ustar james 0000000 0000000 .. _forms:
.. module:: registration.forms
Base form classes
=================
Several form classes are provided with django-registration,
covering common cases for gathering account information and
implementing common constraints for user registration. These forms
were designed with django-registration's built-in registration
workflows in mind, but may also be useful in other situations.
.. class:: RegistrationForm
A simple form for registering an account. This is a subclass of
Django's built-in ``UserCreationForm``, and 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 is represented as
a password input (``input type="password"`` in the rendered
HTML).
``password2``
The password to use for the new account. This is represented as
a password input (``input type="password"`` in the rendered
HTML).
Because this is a subclass of Django's own ``UserCreationForm``,
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.
.. note:: **Unicode usernames**
There is one important difference in form behavior depending on
the version of Python you're using. Django's username validation
regex allows a username to contain any word character along with
the following set of additional characters: ``.@+-``. However,
on Python 2 this regex uses the ``ASCII`` flag (since Python 2's
string type is ASCII by default), while on Python 3 it uses the
``UNICODE`` flag (since Python 3's string type is Unicode). This
means that usernames containing non-ASCII word characters are
only permitted when using Python 3.
The validation error for mismatched passwords is attached to the
``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
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.
django-registration-2.2/docs/hmac.rst 0000644 0000767 0000767 00000023606 13007361451 017146 0 ustar james 0000000 0000000 .. _hmac-workflow:
.. module:: registration.backends.hmac
The HMAC activation workflow
============================
The HMAC workflow, found in ``registration.backends.hmac``, implements
a two-step registration process (signup, followed by activation), but
unlike the older :ref:`model-based activation workflow
` uses no models and does not store its activation
key; instead, the activation key sent to the user is a timestamped,
`HMAC
`_-verified
value.
Unless you need to maintain compatibility in an existing install of
django-registration which used the model-based workflow, it's
recommended you use the HMAC activation workflow for two-step signup
processes.
Behavior and configuration
--------------------------
Since this workflow does not make use of any additional models beyond
the user model (either Django's default
``django.contrib.auth.models.User``, or :ref:`a custom user model
`), *do not* add ``registration`` to your
``INSTALLED_APPS`` setting.
You will need to configure URLs, however. A default URLconf is
provided, which you can ``include()`` in your URL configuration; that
URLconf is ``registration.backends.hmac.urls``. For example, to place
user registration under the URL prefix ``/accounts/``, you could place
the following in your root URLconf:
.. code-block:: python
from django.conf.urls import include, url
urlpatterns = [
# Other URL patterns ...
url(r'^accounts/', include('registration.backends.hmac.urls')),
# More URL patterns ...
]
That URLconf also sets up the views from ``django.contrib.auth``
(login, logout, password reset, etc.), though if you want those views
at a different location, you can ``include()`` the URLconf
``registration.auth_urls`` to place only the ``django.contrib.auth``
views at a specific location in your URL hierarchy.
.. note:: **URL patterns for activation**
Although the actual value used in the activation key is the new
user account's username, the URL pattern for
:class:`~registration.views.backends.hmac.ActivationView` does not
need to match all possible legal characters in a username. The
activation key that will be sent to the user (and thus matched in
the URL) is produced by ``django.core.signing.dumps()``, which
base64-encodes its output. Thus, the only characters this pattern
needs to match are those from `the URL-safe base64 alphabet
`_, plus the colon
("``:``") which is used as a separator.
The default URL pattern for the activation view in
``registration.backends.hmac.urls`` handles this for you.
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` (see also :ref:`note
below `)
By default, this workflow 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 registration view.
Views
-----
.. currentmodule:: registration.backends.hmac.views
Two views are provided to implement the signup/activation
process. These subclass :ref:`the base views of django-registration
`, so anything that can be overridden/customized there can
equally be overridden/customized here. There are some additional
customization points specific to the HMAC implementation, which are
listed below.
For an overview of the templates used by these views (other than those
specified below), and their context variables, see :ref:`the quick
start guide `.
.. class:: RegistrationView
A subclass of :class:`registration.views.RegistrationView`
implementing the signup portion of this workflow.
Important customization points unique to this class are:
.. method:: create_inactive_user(form)
Creates and returns an inactive user account, and calls
:meth:`send_activation_email()` to send the email with the
activation key. The argument ``form`` is a valid registration
form instance passed from
:meth:`~registration.views.RegistrationView.register()`.
.. method:: get_activation_key(user)
Given an instance of the user model, generates and returns an
activation key (a string) for that user account.
.. method:: get_email_context(activation_key)
Returns a dictionary of values to be used as template context
when generating the activation email.
.. method:: send_activation_email(user)
Given an inactive user account, generates and sends the
activation email for that account.
.. attribute:: email_body_template
A string specifying the template to use for the body of the
activation email. Default is
``"registration/activation_email.txt"``.
.. attribute:: email_subject_template
A string specifying the template to use for the subject of the
activation email. Default is
``"registration/activation_email_subject.txt"``. Note that, to
avoid header-injection vulnerabilities, the result of rendering
this template will be forced into a single line of text,
stripping newline characters.
.. class:: ActivationView
A subclass of :class:`registration.views.ActivationView`
implementing the activation portion of this workflow.
Important customization points unique to this class are:
.. method:: get_user(username)
Given a username (determined by the activation key), look up and
return the corresponding instance of the user model. Returns
``None`` if no such instance exists. In the base implementation,
will include ``is_active=False`` in the query to avoid
re-activation of already-active accounts.
.. method:: validate_key(activation_key)
Given the activation key, verifies that it carries a valid
signature and a timestamp no older than the number of days
specified in the setting ``ACCOUNT_ACTIVATION_DAYS``, and
returns the username from the activation key. Returns ``None``
if the activation key has an invalid signature or if the
timestamp is too old.
How it works
------------
When a user signs up, the HMAC workflow creates a new ``User``
instance to represent the account, and sets the ``is_active`` field to
``False``. It then sends an email to the address provided during
signup, containing a link to activate the account. When the user
clicks the link, the activation view sets ``is_active`` to ``True``,
after which the user can log in.
The activation key is simply the username of the new account, signed
using `Django's cryptographic signing tools
`_
(specifically, ``signing.dumps()`` is used, to produce a
guaranteed-URL-safe value). The activation process includes
verification of the signature prior to activation, as well as
verifying that the user is activating within the permitted window (as
specified in the setting ``ACCOUNT_ACTIVATION_DAYS``, mentioned
above), through use of Django's ``TimestampSigner``.
Comparison to the model-activation workflow
-------------------------------------------
The primary advantage of the HMAC activation workflow is that it
requires no persistent storage of the activation key. However, this
means there is no longer an automated way to differentiate accounts
which have been purposefully deactivated (for example, as a way to ban
a user) from accounts which failed to activate within a specified
window. Additionally, it is possible a user could, if manually
deactivated, re-activate their account if still within the activation
window; for this reason, when using the ``is_active`` field to "ban" a
user, it is best to also set the user's password to an unusable value
(i.e., by calling `set_unusable_password()
`_
for that user). Calling ``set_unusable_password()`` will also make it
easier to query for manually-deactivated users, as their passwords
will (when using Django's default ``User`` implementation) begin with
the exclamation mark (``!``) character.
Since the HMAC activation workflow does not use any models, it also
does not make use of the admin interface and thus does not offer a
convenient way to re-send an activation email. Users who have
difficulty receiving the activation email can simply be manually
activated by a site administrator.
However, the reduced overhead of not needing to store the activation
key makes this generally preferable to :ref:`the model-based workflow
`.
Security considerations
-----------------------
The activation key emailed to the user in the HMAC activation workflow
is a value obtained by using Django's cryptographic signing tools.
In particular, the activation key is of the form::
encoded_username:timestamp:signature
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.
Django's implementation uses the value of the ``SECRET_KEY`` setting
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
specified. This value does *not* need to be kept secret (only
``SECRET_KEY`` does); it serves only to ensure that other parts of a
site which also produce signed values from user input could not be
used as a way to generate activation keys for arbitrary usernames (and
vice-versa).
django-registration-2.2/docs/index.rst 0000644 0000767 0000767 00000003121 13007361415 017333 0 ustar james 0000000 0000000 .. _index:
django-registration |version|
=============================
django-registration is a simple, extensible application providing
user registration functionality for `Django
`_-powered Web sites.
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 :ref:`the quick start guide
`, which describes the steps necessary to configure
django-registration for the built-in workflows. For more detailed
information, including how to customize the registration process (and
support for alternate registration systems), read through the
documentation listed below.
.. toctree::
:caption: Installation and configuration
:maxdepth: 1
install
quickstart
.. toctree::
:caption: Built-in registration workflows
:maxdepth: 1
hmac
simple-workflow
model-workflow
.. toctree::
:caption: For developers
:maxdepth: 1
views
forms
custom-user
validators
settings
signals
.. toctree::
:caption: Other documentation
:maxdepth: 1
upgrade
faq
.. seealso::
* `Django's authentication documentation
`_. Django's
authentication system is used by django-registration's default
configuration.
django-registration-2.2/docs/install.rst 0000644 0000767 0000767 00000005611 13007361426 017702 0 ustar james 0000000 0000000 .. _install:
Installation guide
==================
Before installing django-registration, you'll need to have a copy
of `Django `_ already installed. For
information on obtaining and installing Django, consult the `Django
download page `_, which
offers convenient packaged downloads and installation instructions.
The |version| release of django-registration supports Django 1.8,
1.9, and 1.10, on the following Python versions:
* 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.
* Django 1.10 supports Python 2.7, 3.4 and 3.5.
It is expected that django-registration |version| will work
without modification on Python 3.6 once it is released.
.. important:: **Python 3.2**
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.
Normal installation
-------------------
The preferred method of installing django-registration is via
``pip``, the standard Python package-installation tool. If you don't
have ``pip``, instructions are available for `how to obtain and
install it `_. If
you're using Python 2.7.9 or later (for Python 2) or Python 3.4 or
later (for Python 3), ``pip`` came bundled with your installation of
Python.
Once you have ``pip``, simply type::
pip install django-registration
Manual installation
-------------------
It's also possible to install django-registration manually. To do
so, obtain the latest packaged version from `the listing on the Python
Package Index
`_. Unpack the
``.tar.gz`` file, and run::
python setup.py install
Once you've installed django-registration, you can verify
successful installation by opening a Python interpreter and typing
``import registration``.
If the installation was successful, you'll simply get a fresh Python
prompt. If you instead see an ``ImportError``, check the configuration
of your install tools and your Python import path to ensure
django-registration installed into a location Python can import
from.
Installing from a source checkout
---------------------------------
The development repository for django-registration is at
. Presuming you
have `git `_ installed, you can obtain a copy of
the repository by typing::
git clone https://github.com/ubernostrum/django-registration.git
From there, you can use normal git commands to check out the specific
revision you want, and install it using ``python setup.py install``.
Next steps
----------
To get up and running quickly, check out :ref:`the quick start guide
`. For full documentation, see :ref:`the documentation
index `. django-registration-2.2/docs/make.bat 0000644 0000767 0000767 00000005651 12214057645 017117 0 ustar james 0000000 0000000 @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%
)
if "%1" == "" goto help
if "%1" == "help" (
:help
echo.Please use `make ^` where ^ 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 over 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
goto end
)
if "%1" == "clean" (
for /d %%i in (_build\*) do rmdir /q /s %%i
del /q /s _build\*
goto end
)
if "%1" == "html" (
%SPHINXBUILD% -b html %ALLSPHINXOPTS% _build/html
echo.
echo.Build finished. The HTML pages are in _build/html.
goto end
)
if "%1" == "dirhtml" (
%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% _build/dirhtml
echo.
echo.Build finished. The HTML pages are in _build/dirhtml.
goto end
)
if "%1" == "pickle" (
%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% _build/pickle
echo.
echo.Build finished; now you can process the pickle files.
goto end
)
if "%1" == "json" (
%SPHINXBUILD% -b json %ALLSPHINXOPTS% _build/json
echo.
echo.Build finished; now you can process the JSON files.
goto end
)
if "%1" == "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.
goto end
)
if "%1" == "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.ghc
goto end
)
if "%1" == "latex" (
%SPHINXBUILD% -b latex %ALLSPHINXOPTS% _build/latex
echo.
echo.Build finished; the LaTeX files are in _build/latex.
goto end
)
if "%1" == "changes" (
%SPHINXBUILD% -b changes %ALLSPHINXOPTS% _build/changes
echo.
echo.The overview file is in _build/changes.
goto end
)
if "%1" == "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.
goto end
)
if "%1" == "doctest" (
%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% _build/doctest
echo.
echo.Testing of doctests in the sources finished, look at the ^
results in _build/doctest/output.txt.
goto end
)
:end
django-registration-2.2/docs/Makefile 0000644 0000767 0000767 00000005713 12214057645 017151 0 ustar james 0000000 0000000 # 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 ' where 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."
django-registration-2.2/docs/model-workflow.rst 0000644 0000767 0000767 00000024713 13011526040 021176 0 ustar james 0000000 0000000 .. _model-workflow:
.. module:: registration.backends.model_activation
The model-based activation workflow
===================================
This workflow implements a two-step -- registration, followed by
activation -- process for user signup.
.. note:: **Use of the model-based workflow is discouraged**
The model-based activation workflow was originally the *only*
workflow built in to django-registration, and later was the
default one. However, it no longer represents the best practice for
registration with modern versions of Django, and so it continues to
be included only for backwards compatibility with existing
installations of django-registration.
If you're setting up a new installation and want a two-step process
with activation, it's recommended you use :ref:`the HMAC activation
workflow ` instead.
Also, note that this workflow was previously found in
``registration.backends.default``, and imports from that location
still function in django-registration |version| but now raise
deprecation warnings. The correct location going forward is
``registration.backends.model_activation``.
Default behavior and configuration
----------------------------------
To make use of this workflow, simply add ``registration`` to your
``INSTALLED_APPS``, run ``manage.py migrate`` to install its model,
and include the URLconf
``registration.backends.model_activation.urls`` at whatever location
you choose in your URL hierarchy. For example:
.. code-block:: python
from django.conf.urls import include, url
urlpatterns = [
# Other URL patterns ...
url(r'^accounts/', include('registration.backends.model_activation.urls')),
# More URL patterns ...
]
This workflow makes use of the following settings:
* :data:`~django.conf.settings.ACCOUNT_ACTIVATION_DAYS`
* :data:`~django.conf.settings.REGISTRATION_OPEN`
By default, this workflow 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 registration view.
Two views are provided:
``registration.backends.model_activation.views.RegistrationView`` and
``registration.backends.model_activation.views.ActivationView``. These
views subclass django-registration's base
:class:`~registration.views.RegistrationView` and
:class:`~registration.views.ActivationView`, respectively, and
implement the two-step registration/activation process.
Upon successful registration -- not activation -- the user will be
redirected to the URL pattern named ``registration_complete``.
Upon successful activation, the user will be redirected to the URL
pattern named ``registration_activation_complete``.
This workflow uses the same templates and contexts as :ref:`the HMAC
activation workflow `, which is covered in :ref:`the
quick-start guide `. Refer to the quick-start guide
for documentation on those templates and their contexts.
How account data is stored for activation
-----------------------------------------
During registration, a new instance of the user model (by default,
Django's ``django.contrib.auth.models.User`` -- see :ref:`the custom
user documentation ` for notes on using a different
model) 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 ``OneToOneField`` to the user model, 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. Initially, the activation key is the hex digest of a
SHA1 hash; after activation, this is reset to :attr:`ACTIVATED`.
Additionally, one class attribute exists:
.. attribute:: ACTIVATED
A constant string used as the value of :attr:`activation_key`
for accounts which have been activated.
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:`activation_key` is :attr:`ACTIVATED`, 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)
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``.
``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
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
`_
for details regarding these objects' interfaces.
Note that, to avoid header-injection vulnerabilities, 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``
: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.activation_key` of the
:class:`RegistrationProfile` for the account will be set to
:attr:`RegistrationProfile.ACTIVATED` 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:: expired
Return instances of :class:`RegistrationProfile` corresponding
to expired users. A user is considered to be "expired" if:
* The activation key of the user's :class:`RegistrationProfile`
is not set to :attr:`RegistrationProfile.ACTIVATED`, and
* The user's ``is_active`` field of is ``False``, and
* The user's ``date_joined`` field is more than
:data:`~django.conf.settings.ACCOUNT_ACTIVATION_DAYS` in the
past.
:rtype: ``QuerySet`` of :class:`RegistrationProfile`
.. 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.
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(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 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
: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
.. 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``
django-registration-2.2/docs/quickstart.rst 0000644 0000767 0000767 00000023143 13007361444 020426 0 ustar james 0000000 0000000 .. _quickstart:
Quick start guide
=================
First you'll need to have Django and django-registration
installed; for details on that, see :ref:`the installation guide
`.
The next steps will depend on which registration workflow you'd like
to use. There are three workflows built in to django-registration;
one is included largely for backwards compatibility with older
releases, while the other two are recommended for new
installations. Those two are:
* :ref:`The HMAC activation workflow `, which
implements a two-step process: a user signs up, then is emailed an
activation link and must click it to activate the account.
* :ref:`The simple one-step workflow `, in which a
user simply signs up and their account is immediately active and
logged in.
The guide below covers use of these two workflows.
.. 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
`_,
you'll probably want to pause and read :ref:`the custom user
compatibility guide ` before using
django-registration.
Configuring the HMAC activation workflow
----------------------------------------
The configuration process for using the HMAC activation workflow is
straightforward: you'll need to specify a couple of settings, connect
some URLs and create a few templates.
Required settings
~~~~~~~~~~~~~~~~~
Begin by adding the following setting to your Django settings file:
:data:`~django.conf.settings.ACCOUNT_ACTIVATION_DAYS`
This is the number of days users will have to activate their
accounts after registering. If a user does not activate within
that period, the account will remain permanently inactive unless a
site administrator manually activates it.
For example, you might have something like the following in your
Django settings::
ACCOUNT_ACTIVATION_DAYS = 7 # One-week activation window; you may, of course, use a different value.
You'll also need to have ``django.contrib.auth`` in your
``INSTALLED_APPS`` setting, since all of the registration workflows in
django-registration make use of it.
.. warning:: You should **not** add ``registration`` to your
``INSTALLED_APPS`` setting if you're following this document. This
section is walking you through setup of the :ref:`the HMAC
activation workflow `, and that does not make use of
any custom models or other features which require ``registration``
to be in ``INSTALLED_APPS``. Only add ``registration`` to your
``INSTALLED_APPS`` setting if you're using :ref:`the model-based
activation workflow `, or something derived from
it.
Setting up URLs
~~~~~~~~~~~~~~~
Each bundled registration workflow in django-registration includes
a Django URLconf which sets up URL patterns for :ref:`the views in
django-registration `, as well as several useful views in
``django.contrib.auth`` (e.g., login, logout, password
change/reset). The URLconf for the HMAC activation workflow can be
found at ``registration.backends.hmac.urls``, and so can simply be
included in your project's root URL configuration. For example, to
place the URLs under the prefix ``/accounts/``, you could add the
following to your project's root URLconf:
.. code-block:: python
from django.conf.urls import include, url
urlpatterns = [
# Other URL patterns ...
url(r'^accounts/', include('registration.backends.hmac.urls')),
# More URL patterns ...
]
Users would then be able to register by visiting the URL
``/accounts/register/``, log in (once activated) at
``/accounts/login/``, etc.
Another ``URLConf`` is also provided -- at ``registration.auth_urls``
-- which just handles the Django auth views, should you want to put
those at a different location.
.. _default-templates:
Required templates
~~~~~~~~~~~~~~~~~~
You will also need to create several templates required by
django-registration, and possibly additional templates required by
views in ``django.contrib.auth``. The templates required by
django-registration are as follows; note that, with the exception
of the templates used for account activation emails, all of these are
rendered using a ``RequestContext`` and so will also receive any
additional variables provided by `context processors
`_.
**registration/registration_form.html**
Used to show the form users will fill out to register. By default, has
the following context:
``form``
The registration form. This will likely be a subclass of
:class:`~registration.forms.RegistrationForm`; consult `Django's
forms documentation
`_ for
information on how to display this in a template.
**registration/registration_complete.html**
Used after successful completion of the registration form. This
template has no context variables of its own, and should simply inform
the user that an email containing account-activation information has
been sent.
**registration/activate.html**
Used if account activation fails. With the default setup, has the following context:
``activation_key``
The activation key used during the activation attempt.
**registration/activation_complete.html**
Used after successful account activation. This template has no context
variables of its own, and should simply inform the user that their
account is now active.
**registration/activation_email_subject.txt**
Used to generate the subject line of the activation email. Because the
subject line of an email must be a single line of text, any output
from this template will be forcibly condensed to a single line before
being used. This template has the following context:
``activation_key``
The activation key for the new account.
``expiration_days``
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
may be an instance of either ``django.contrib.sites.models.Site``
(if the sites application is installed) or
``django.contrib.sites.requests.RequestSite`` (if not). Consult
`the documentation for the Django sites framework
`_ for
details regarding these objects' interfaces.
**registration/activation_email.txt**
Used to generate the body of the activation email. Should display a
link the user can click to activate the account. This template has the
following context:
``activation_key``
The activation key for the new account.
``expiration_days``
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
may be an instance of either ``django.contrib.sites.models.Site``
(if the sites application is installed) or
``django.contrib.sites.requests.RequestSite`` (if not). Consult
`the documentation for the Django sites framework
`_ for
details regarding these objects.
Note that the templates used to generate the account activation email
use the extension ``.txt``, not ``.html``. Due to widespread antipathy
toward and interoperability problems with HTML email,
django-registration defaults to plain-text email, and so these
templates should simply output plain text rather than HTML.
To make use of the views from ``django.contrib.auth`` (which are set
up for you by the default URLconf mentioned above), you will also need
to create the templates required by those views. Consult `the
documentation for Django's authentication system
`_ for details
regarding these templates.
Configuring the simple one-step workflow
--------------------------------------------
Also included is a simpler, :ref:`one-step registration workflow
`, where a user signs up and their account is
immediately active and logged in.
The simple workflow does not require any models other than those
provided by Django's own authentication system, so only
``django.contrib.auth`` needs to be in your ``INSTALLED_APPS``
setting.
You will need to configure URLs to use the simple workflow; the
easiest way is to simply ``include()`` the URLconf
``registration.backends.simple.urls`` in your root URLconf. For
example, to place the URLs under the prefix ``/accounts/`` in your URL
structure:
.. code-block:: python
from django.conf.urls import include, url
urlpatterns = [
# Other URL patterns ...
url(r'^accounts/', include('registration.backends.simple.urls')),
# More URL patterns ...
]
Users could then register accounts by visiting the URL
``/accounts/register/``.
This URLconf will also configure the appropriate URLs for the rest of
the built-in ``django.contrib.auth`` views (log in, log out, password
reset, etc.).
Finally, you will need to create one template:
``registration/registration_form.html``. See :ref:`the list of
templates above ` for details of this template's
context.
django-registration-2.2/docs/settings.rst 0000644 0000767 0000767 00000003742 13007361542 020076 0 ustar james 0000000 0000000 .. _settings:
.. module:: django.conf.settings
Custom settings
===============
Although the choice of registration workflow does not necessarily
require changes to your Django settings (as registration workflows are
selected by including the appropriate URL patterns in your root
URLconf), the built-in workflows of django-registration make use
of several custom settings.
.. data:: ACCOUNT_ACTIVATION_DAYS
An ``int`` indicating how long (in days) after signup an account
has in which to activate.
This setting is required if using one of the built-in two-step
workflows:
* :ref:`The two-step HMAC activation workflow `
* :ref:`The model-based activation workflow `
.. data:: REGISTRATION_OPEN
A ``bool`` indicating whether registration of new accounts is
currently permitted.
A default of ``True`` is assumed when this setting is not supplied,
so specifying it is optional unless you want to temporarily close
registration (in which case, set it to ``False``).
Used by:
* :ref:`The two-step HMAC activation workflow `
* :ref:`The simple one-step workflow `
* :ref:`The model-based activation workflow `
Third-party workflows wishing to use an alternate method of
determining whether registration is allowed should subclass
:class:`registration.views.RegistrationView` (or a subclass of it
from an existing workflow) and override
:meth:`~registration.views.RegistrationView.registration_allowed`.
.. data:: REGISTRATION_SALT
A ``str`` used as an additional "salt" in the process of generating
HMAC-signed activation keys.
This setting is optional, and a default of ``"registration"`` will
be used if not specified. The value of this setting does not need
to be kept secret; see :ref:`the note about this salt value and
security ` for details.
Used by:
* :ref:`The two-step HMAC activation workflow `
django-registration-2.2/docs/signals.rst 0000644 0000767 0000767 00000004723 13007361553 017700 0 ustar james 0000000 0000000 .. _signals:
.. module:: registration.signals
Signals used by django-registration
===================================
Much of django-registration's customizability comes through the
ability to write and use different workflows for user
registration. However, there are many cases where only a small bit of
additional logic needs to be injected into the registration process,
and writing a custom workflow to support this represents an
unnecessary amount of work. A more lightweight customization option is
provided through two custom signals which the built-in registration
workflows send, and custom workflows are encouraged to send, at
specific points during the registration process; functions listening
for these signals can then add whatever logic is needed.
For general documentation on signals and the Django dispatcher,
consult `Django's signals documentation
`_. This
documentation assumes that you are familiar with how signals work and
the process of writing and connecting functions which will listen for
signals.
.. data:: user_activated
Sent when a user account is activated (not applicable to all
workflows). Provides the following arguments:
``sender``
The :class:`~registration.views.ActivationView` subclass used
to activate the user.
``user``
A user-model instance representing the activated account.
``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
Sent when a new user account is registered. Provides the following
arguments:
``sender``
The :class:`~registration.views.RegistrationView` subclass used
to register the account.
``user``
A user-model instance representing the new account.
``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. django-registration-2.2/docs/simple-workflow.rst 0000644 0000767 0000767 00000004557 13007361460 021403 0 ustar james 0000000 0000000 .. _simple-workflow:
.. module:: registration.backends.simple
The simple one-step workflow
============================
As an alternative to the :ref:`HMAC ` and
:ref:`model-based ` two-step (registration and
activation) workflows, django-registration bundles a one-step
registration workflow in ``registration.backends.simple``. This
workflow is deliberately as simple as possible:
1. A user signs up by filling out a registration form.
2. The user's account is created and is active immediately, with no
intermediate confirmation or activation step.
3. The new user is logged in immediately.
Configuration
-------------
To use this workflow, simply include the URLconf
``registration.backends.simple.urls`` somewhere in your site's own URL
configuration. For example:
.. code-block:: python
from django.conf.urls import include, url
urlpatterns = [
# Other URL patterns ...
url(r'^accounts/', include('registration.backends.simple.urls')),
# More URL patterns ...
]
To control whether registration of new accounts is allowed, you can
specify the setting :data:`~django.conf.settings.REGISTRATION_OPEN`.
Upon successful registration, the user will be redirected to the
site's home page -- the URL ``/``. This can be changed by subclassing
``registration.backends.simple.views.RegistrationView`` and overriding
the method ``get_success_url()``.
The default form class used for account registration will be
:class:`registration.forms.RegistrationForm`, although this can be
overridden by supplying a custom URL pattern for the registration view
and passing the keyword argument ``form_class``, or by subclassing
``registration.backends.simple.views.RegistrationView`` and either
overriding ``form_class`` or implementing
:meth:`~registration.views.RegistrationView.get_form_class()`, and
specifying the custom subclass in your URL patterns.
Templates
---------
The one-step workflow uses only one custom template:
**registration/registration_form.html**
Used to show the form users will fill out to register. By default, has
the following context:
``form``
The registration form. This will likely be a subclass of
:class:`~registration.forms.RegistrationForm`; consult `Django's
forms documentation
`_ for
information on how to display this in a template.
django-registration-2.2/docs/upgrade.rst 0000644 0000767 0000767 00000016602 13011526224 017657 0 ustar james 0000000 0000000 .. _upgrade:
Upgrading from previous versions
================================
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
upgrading from django-registration 0.8, as well as from 1.0.
Backends are now class-based views
----------------------------------
In django-registration 0.8, a registration workflow was
implemented as a class with specific methods for the various steps of
the registration process. In django-registration 2.0 and later, a
registration workflow is implemented as one or more class-based views.
In general, the required changes to implement a 0.8 registration
workflow in django-registration |version| is:
+-------------------------------------------------------------+------------------------------------------------------------------+
| 0.8 backend class implementation | 2.0+ view subclass implementation |
+=============================================================+==================================================================+
| Backend class implementing ``register()`` | :meth:`registration.views.RegistrationView.register` |
+-------------------------------------------------------------+------------------------------------------------------------------+
| Backend class implementing ``activate()`` | :meth:`registration.views.ActivationView.activate` |
+-------------------------------------------------------------+------------------------------------------------------------------+
| Backend class implementing ``registration_allowed()`` | :meth:`registration.views.RegistrationView.registration_allowed` |
+-------------------------------------------------------------+------------------------------------------------------------------+
| Backend class implementing ``get_form_class()`` | :meth:`registration.views.RegistrationView.get_form_class()` |
+-------------------------------------------------------------+------------------------------------------------------------------+
| Backend class implementing ``post_registration_redirect()`` | :meth:`registration.views.RegistrationView.get_success_url()` |
+-------------------------------------------------------------+------------------------------------------------------------------+
| Backend class implementing ``post_activation_redirect()`` | :meth:`registration.views.ActivationView.get_success_url()` |
+-------------------------------------------------------------+------------------------------------------------------------------+
URLconf changes
---------------
If you were using one of the provided workflows in
django-registration 0.8 without modification, you will not need to
make any changes; both ``registration.backends.default.urls`` and
``registration.backends.simple.urls`` have been updated in
django-registration 2.0+ to correctly point to the new
class-based views:
+---------------------------------+---------------------------------------------------+
| 0.8 URLconf view reference | |version| URLconf view reference |
+=================================+===================================================+
| ``registration.views.register`` | ``registration.views.RegistrationView.as_view()`` |
+---------------------------------+---------------------------------------------------+
| ``registration.views.activate`` | ``registration.views.ActivationView.as_view()`` |
+---------------------------------+---------------------------------------------------+
However, if you were using the two-step model-activation workflow, you
should begin referring to
``registration.backends.model_activation.urls`` instead of
``registration.backends.default.urls`` or ``registration.urls``, as
the latter two are deprecated and support for them will be removed in
a future release.
If you were passing custom arguments to the built-in registration
views, those arguments should continue to work, so long as your
URLconf is updated to refer to the new class-based views. For details
of how to pass custom arguments to class-based views, see `the Django
class-based view documentation
`_.
Template changes
----------------
When using :class:`~registration.forms.RegistrationForm`, the error
from mismatched passwords now is attached to the ``password2`` field
rather than being a form-level error. To check for and display this
error, you will need to change to accessing it via the ``password2``
field rather than via ``non_field_errors()`` or the ``__all__`` key in
the errors dictionary.
Changes since 1.0
-----------------
If you used django-registration 1.0, or a pre-2.0 checkout of the
code, you will need to make some minor adjustments.
If you previously used ``registration.backends.default``, you will now
see deprecation warnings, as the former "default" workflow is now
found in ``registration.backends.model_activation``. Use of
``registration.backends.default`` continues to work in
django-registration |version|, but will be removed in the future.
Similarly, references to ``registration.urls`` should become
references to ``registration.backends.model_activation.urls``, and
``registration.urls`` is deprecated and will be removed in a future
release.
If you had written custom subclasses of
:class:`~registration.views.RegistrationView` or of
``RegistrationView`` subclasses in the built-in workflows, the
following changes need to be noted:
* The ``register`` method now receives the
:class:`~registration.forms.RegistrationForm` instance used during
signup, rather than keyword arguments corresponding to the form's
``cleaned_data``.
* ``RegistrationForm`` itself is now a subclass of Django's built-in
``UserCreationForm``, and as such is now a ``ModelForm``
subclass. This can cause metaclass conflict errors if you write a
class which is a subclass of both ``RegistrationForm`` and a
non-``ModelForm`` form class; to avoid this, ensure that subclasses
of ``RegistrationForm`` and/or ``ModelForm`` come first in your
subclass' method resolution order.
* 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 in version 2.1 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, but was
included because the security benefits outweigh the edge cases of the
now-disallowed usernames. 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.
In |version|, the behavior of the
:meth:`~registration.models.RegistrationProfile.expired` method was
clarified to accommodate user expectations; it does *not* return (and
thus,
:meth:`~registration.models.RegistrationProfile.delete_expired_users`
does not delete) profiles of users who had successfully activated. django-registration-2.2/docs/validators.rst 0000644 0000767 0000767 00000010403 13007361533 020376 0 ustar james 0000000 0000000 .. _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
`_)
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
`_).
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
`_.
.. 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`. django-registration-2.2/docs/views.rst 0000644 0000767 0000767 00000013275 13007361475 017402 0 ustar james 0000000 0000000 .. _views:
.. module:: registration.views
Base view classes
=================
In order to allow the utmost flexibility in customizing and supporting
different workflows, django-registration makes use of Django's
support for `class-based views
`_. Included
in django-registration are two base classes which can be
subclassed to implement whatever workflow is required.
The built-in workflows in django-registration provide their own
subclasses of these views, and the documentation for those workflows
will indicate customization points specific to those subclasses. The
following reference covers useful attributes and methods of the base
classes, for use in writing your own custom subclasses.
.. class:: RegistrationView
A subclass of Django's `FormView
`_,
which provides the infrastructure for supporting user registration.
Since it's a subclass of ``FormView``, ``RegistrationView`` has all
the usual attributes and methods you can override.
When writing your own subclass, one method is required:
.. method:: register(form)
Implement your registration logic here. ``form`` will be the
(already-validated) form filled out by the user during the
registration process (i.e., a valid instance of
:class:`registration.forms.RegistrationForm` or a subclass of
it).
This method should return the newly-registered user instance,
and should send the signal
: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:
.. attribute:: disallowed_url
The URL to redirect to when registration is disallowed. Should
be a `string name of a URL pattern
`_.
Default value is ``"registration_disallowed"``.
.. attribute:: form_class
The form class to use for user registration. Can be overridden
on a per-request basis (see below). Should be the actual class
object; by default, this class is
:class:`registration.forms.RegistrationForm`.
.. attribute:: success_url
The URL to redirect to after successful registration. A string
containing a (relative) URL, or a string name of a URL pattern,
or a 3-tuple of arguments suitable for passing to Django's
`redirect shortcut
`_. Can
be overridden on a per-request basis (see below). Default value
is ``None``, so that per-request customization is used instead.
.. attribute:: template_name
The template to use for user registration. Should be a
string. Default value is
``registration/registration_form.html``.
.. method:: get_form_class()
Select a form class to use on a per-request basis. If not
overridden, will use :attr:`~form_class`. Should be the actual
class object.
.. method:: get_success_url(user)
Return a URL to redirect to after successful registration, on a
per-request or per-user basis. If not overridden, will use
:attr:`~success_url`. Should return a string containing a
(relative) URL, or a string name of a URL pattern, or a 3-tuple
of arguments suitable for passing to Django's ``redirect``
shortcut.
.. method:: registration_allowed()
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
`_,
``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. The relevant bug was fixed in
Django 1.9.1, but django-registration will continue to work
around it for as long as the Django 1.9 release series is
supported.
.. class:: ActivationView
A subclass of Django's `TemplateView
`_
which provides support for a separate account-activation step, in
workflows which require that.
One method is required:
.. method:: activate(*args, **kwargs)
Implement your activation logic here. You are free to configure
your URL patterns to pass any set of positional or keyword
arguments to ``ActivationView``, and they will in turn be passed
to this method.
This method should return the newly-activated user instance (if
activation was successful), or boolean ``False`` if activation
was not successful.
Useful places to override or customize on an ``ActivationView``
subclass are:
.. attribute:: template_name
The template to use for user activation. Should be a
string. Default value is ``registration/activate.html``.
.. method:: get_success_url(user)
Return a URL to redirect to after successful registration, on a
per-request or per-user basis. If not overridden, will use
:attr:`~success_url`. Should return a string containing a
(relative) URL, or a string name of a URL pattern, or a 3-tuple
of arguments suitable for passing to Django's ``redirect``
shortcut.
django-registration-2.2/LICENSE 0000644 0000767 0000767 00000002763 12726166473 015600 0 ustar james 0000000 0000000 Copyright (c) 2007-2016, 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.
django-registration-2.2/MANIFEST.in 0000644 0000767 0000767 00000000246 12214057645 016313 0 ustar james 0000000 0000000 include CHANGELOG
include INSTALL
include LICENSE
include MANIFEST.in
include README
include AUTHORS
recursive-include docs *
recursive-include registration/locale *
django-registration-2.2/PKG-INFO 0000644 0000767 0000767 00000002226 13011716531 015642 0 ustar james 0000000 0000000 Metadata-Version: 1.1
Name: django-registration
Version: 2.2
Summary: An extensible user-registration application for Django
Home-page: https://github.com/ubernostrum/django-registration/
Author: James Bennett
Author-email: james@b-list.org
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Framework :: Django
Classifier: Framework :: Django :: 1.8
Classifier: Framework :: Django :: 1.9
Classifier: Framework :: Django :: 1.10
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Topic :: Software Development :: Libraries :: Python Modules
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.3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Topic :: Utilities
django-registration-2.2/README.rst 0000644 0000767 0000767 00000000753 13007332734 016243 0 ustar james 0000000 0000000 .. -*-restructuredtext-*-
.. image:: https://travis-ci.org/ubernostrum/django-registration.svg?branch=master
:target: https://travis-ci.org/ubernostrum/django-registration
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.8 or newer, but has no
other dependencies.
Full documentation is `available online
`_.
django-registration-2.2/registration/ 0000755 0000767 0000767 00000000000 13011716531 017255 5 ustar james 0000000 0000000 django-registration-2.2/registration/__init__.py 0000644 0000767 0000767 00000001232 13011716336 021367 0 ustar james 0000000 0000000 VERSION = (2, 2, 0, 'final', 0)
def get_version():
"""
Returns a PEP 386-compliant version number from VERSION.
"""
assert len(VERSION) == 5
assert VERSION[3] in ('alpha', 'beta', 'rc', 'final')
# Now build the two parts of the version number:
# main = X.Y[.Z]
# sub = .devN - for pre-alpha releases
# | {a|b|c}N - for alpha, beta and rc releases
parts = 2 if VERSION[2] == 0 else 3
main = '.'.join(str(x) for x in VERSION[:parts])
sub = ''
if VERSION[3] != 'final':
mapping = {'alpha': 'a', 'beta': 'b', 'rc': 'c'}
sub = mapping[VERSION[3]] + str(VERSION[4])
return str(main + sub)
django-registration-2.2/registration/admin.py 0000644 0000767 0000767 00000003420 12726166473 020736 0 ustar james 0000000 0000000 """
Admin class for the RegistrationProfile model, providing several
conveniences.
This is only enabled if 'registration' is in your INSTALLED_APPS
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 _
from registration.models import RegistrationProfile
class RegistrationAdmin(admin.ModelAdmin):
actions = ['activate_users', 'resend_activation_email']
list_display = ('user', 'activation_key_expired')
raw_id_fields = ['user']
search_fields = ('user__username', 'user__first_name', 'user__last_name')
def activate_users(self, request, queryset):
"""
Activate the selected users, if they are not alrady
activated.
"""
for profile in queryset:
RegistrationProfile.objects.activate_user(profile.activation_key)
activate_users.short_description = _(u"Activate users")
def resend_activation_email(self, request, queryset):
"""
Re-send activation emails for the selected users.
Note that this will *only* send activation emails for users
who are eligible to activate; emails will not be sent to users
whose activation keys have expired or who have already
activated.
"""
for profile in queryset:
if not profile.activation_key_expired():
profile.send_activation_email(
get_current_site(request)
)
resend_activation_email.short_description = _(u"Re-send activation emails")
if apps.is_installed('registration'):
admin.site.register(RegistrationProfile, RegistrationAdmin)
django-registration-2.2/registration/auth_urls.py 0000644 0000767 0000767 00000003421 12726166473 021655 0 ustar james 0000000 0000000 """
URL patterns for the views included in ``django.contrib.auth``.
Including these URLs (via the ``include()`` directive) will set up
these patterns based at whatever URL prefix they are included under.
The URLconfs in the built-in registration workflows already have an
``include()`` for these URLs, so if you're using one of them it is not
necessary to manually include these views.
"""
from django.conf.urls import url
from django.contrib.auth import views as auth_views
urlpatterns = [
url(r'^login/$',
auth_views.login,
{'template_name': 'registration/login.html'},
name='auth_login'),
url(r'^logout/$',
auth_views.logout,
{'template_name': 'registration/logout.html'},
name='auth_logout'),
url(r'^password/change/$',
auth_views.password_change,
{'post_change_redirect': 'auth_password_change_done'},
name='auth_password_change'),
url(r'^password/change/done/$',
auth_views.password_change_done,
name='auth_password_change_done'),
url(r'^password/reset/$',
auth_views.password_reset,
{'post_reset_redirect': 'auth_password_reset_done',
'email_template_name': 'registration/password_reset_email.txt'},
name='auth_password_reset'),
url(r'^password/reset/confirm/(?P[0-9A-Za-z_\-]+)/'
r'(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
auth_views.password_reset_confirm,
{'post_reset_redirect': 'auth_password_reset_complete'},
name='auth_password_reset_confirm'),
url(r'^password/reset/complete/$',
auth_views.password_reset_complete,
name='auth_password_reset_complete'),
url(r'^password/reset/done/$',
auth_views.password_reset_done,
name='auth_password_reset_done'),
]
django-registration-2.2/registration/backends/ 0000755 0000767 0000767 00000000000 13011716531 021027 5 ustar james 0000000 0000000 django-registration-2.2/registration/backends/__init__.py 0000644 0000767 0000767 00000000000 12214057645 023136 0 ustar james 0000000 0000000 django-registration-2.2/registration/backends/default/ 0000755 0000767 0000767 00000000000 13011716531 022453 5 ustar james 0000000 0000000 django-registration-2.2/registration/backends/default/__init__.py 0000644 0000767 0000767 00000001177 12575163044 024603 0 ustar james 0000000 0000000 """
Backwards-compatible import location for the model-based activation
workflow.
Formerly this was the default registration workflow of
django-registration, and so was found at
registration.backends.default. As of the current release, however, it
is no longer the default workflow (there is now no default), and has
accordingly been moved to registration.backends.model_activation.
Attempting to import the views or include() the URLconf found here
will raise deprecation warnings to make users aware of this fact, and
remind them to modify imports and include()s, as support for this
location will be removed in a future release.
"""
django-registration-2.2/registration/backends/default/urls.py 0000644 0000767 0000767 00000001155 12604633610 024017 0 ustar james 0000000 0000000 """
Backwards-compatible support for include()-ing the model-based
activation workflow's URLconf.
The new location for that URLconf is
registration.backends.model_activation.urls. Using include() with
registration.backends.default.urls will raise deprecation warnings,
and support for it will be removed in a future release.
"""
import warnings
from registration.backends.model_activation import urls as model_urls
warnings.warn(
"registration.backends.default.urls is deprecated; "
"use registration.backends.model_activation.urls instead.",
DeprecationWarning
)
urlpatterns = model_urls.urlpatterns
django-registration-2.2/registration/backends/default/views.py 0000644 0000767 0000767 00000001232 12604633610 024163 0 ustar james 0000000 0000000 """
Backwards-compatible support for importing the model-based activation
workflow's views.
The new location for those views is
registration.backends.model_activation.views. Importing from
registration.backends.default will raise deprecation warnings, and
support for it will be removed in a future release.
"""
import warnings
from registration.backends.model_activation import views as new_location
warnings.warn(
"registration.backends.default.views is deprecated; "
"use registration.backends.model_activation.views instead.",
DeprecationWarning
)
ActivationView = new_location.ActivationView
RegistrationView = new_location.RegistrationView
django-registration-2.2/registration/backends/hmac/ 0000755 0000767 0000767 00000000000 13011716531 021737 5 ustar james 0000000 0000000 django-registration-2.2/registration/backends/hmac/__init__.py 0000644 0000767 0000767 00000000554 13007332734 024060 0 ustar james 0000000 0000000 """
A two-step (signup, then activation) registration workflow, using
HMAC-signed tokens.
To use, include() the provided URLconf --
registration.backends.hmac.urls -- somewhere in your URL
configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
https://django-registration.readthedocs.io/
"""
django-registration-2.2/registration/backends/hmac/urls.py 0000644 0000767 0000767 00000002261 12726166473 023317 0 ustar james 0000000 0000000 """
URLconf for registration and activation, using django-registration's
HMAC activation workflow.
"""
from django.conf.urls import include, url
from django.views.generic.base import TemplateView
from . import views
urlpatterns = [
url(r'^activate/complete/$',
TemplateView.as_view(
template_name='registration/activation_complete.html'
),
name='registration_activation_complete'),
# The activation key can make use of any character from the
# URL-safe base64 alphabet, plus the colon as a separator.
url(r'^activate/(?P[-:\w]+)/$',
views.ActivationView.as_view(),
name='registration_activate'),
url(r'^register/$',
views.RegistrationView.as_view(),
name='registration_register'),
url(r'^register/complete/$',
TemplateView.as_view(
template_name='registration/registration_complete.html'
),
name='registration_complete'),
url(r'^register/closed/$',
TemplateView.as_view(
template_name='registration/registration_closed.html'
),
name='registration_disallowed'),
url(r'', include('registration.auth_urls')),
]
django-registration-2.2/registration/backends/hmac/views.py 0000644 0000767 0000767 00000012027 12726166473 023470 0 ustar james 0000000 0000000 """
A two-step (registration followed by activation) workflow, implemented
by emailing an HMAC-verified timestamped activation token to the user
on signup.
"""
from django.conf import settings
from django.contrib.auth import get_user_model
from django.contrib.sites.shortcuts import get_current_site
from django.core import signing
from django.template.loader import render_to_string
from registration import signals
from registration.views import ActivationView as BaseActivationView
from registration.views import RegistrationView as BaseRegistrationView
REGISTRATION_SALT = getattr(settings, 'REGISTRATION_SALT', 'registration')
class RegistrationView(BaseRegistrationView):
"""
Register a new (inactive) user account, generate an activation key
and email it to the user.
This is different from the model-based activation workflow in that
the activation key is simply the username, signed using Django's
TimestampSigner, with HMAC verification on activation.
"""
email_body_template = 'registration/activation_email.txt'
email_subject_template = 'registration/activation_email_subject.txt'
def register(self, form):
new_user = self.create_inactive_user(form)
signals.user_registered.send(sender=self.__class__,
user=new_user,
request=self.request)
return new_user
def get_success_url(self, user):
return ('registration_complete', (), {})
def create_inactive_user(self, form):
"""
Create the inactive user account and send an email containing
activation instructions.
"""
new_user = form.save(commit=False)
new_user.is_active = False
new_user.save()
self.send_activation_email(new_user)
return new_user
def get_activation_key(self, user):
"""
Generate the activation key which will be emailed to the user.
"""
return signing.dumps(
obj=getattr(user, user.USERNAME_FIELD),
salt=REGISTRATION_SALT
)
def get_email_context(self, activation_key):
"""
Build the template context used for the activation email.
"""
return {
'activation_key': activation_key,
'expiration_days': settings.ACCOUNT_ACTIVATION_DAYS,
'site': get_current_site(self.request)
}
def send_activation_email(self, user):
"""
Send the activation email. The activation key is simply the
username, signed using TimestampSigner.
"""
activation_key = self.get_activation_key(user)
context = self.get_email_context(activation_key)
context.update({
'user': user
})
subject = render_to_string(self.email_subject_template,
context)
# Force subject to a single line to avoid header-injection
# issues.
subject = ''.join(subject.splitlines())
message = render_to_string(self.email_body_template,
context)
user.email_user(subject, message, settings.DEFAULT_FROM_EMAIL)
class ActivationView(BaseActivationView):
"""
Given a valid activation key, activate the user's
account. Otherwise, show an error message stating the account
couldn't be activated.
"""
def activate(self, *args, **kwargs):
# This is safe even if, somehow, there's no activation key,
# because unsign() will raise BadSignature rather than
# TypeError on a value of None.
username = self.validate_key(kwargs.get('activation_key'))
if username is not None:
user = self.get_user(username)
if user is not None:
user.is_active = True
user.save()
return user
return False
def get_success_url(self, user):
return ('registration_activation_complete', (), {})
def validate_key(self, activation_key):
"""
Verify that the activation key is valid and within the
permitted activation time window, returning the username if
valid or ``None`` if not.
"""
try:
username = signing.loads(
activation_key,
salt=REGISTRATION_SALT,
max_age=settings.ACCOUNT_ACTIVATION_DAYS * 86400
)
return username
# SignatureExpired is a subclass of BadSignature, so this will
# catch either one.
except signing.BadSignature:
return None
def get_user(self, username):
"""
Given the verified username, look up and return the
corresponding user account if it exists, or ``None`` if it
doesn't.
"""
User = get_user_model()
lookup_kwargs = {
User.USERNAME_FIELD: username,
'is_active': False
}
try:
user = User.objects.get(**lookup_kwargs)
return user
except User.DoesNotExist:
return None
django-registration-2.2/registration/backends/model_activation/ 0000755 0000767 0000767 00000000000 13011716531 024350 5 ustar james 0000000 0000000 django-registration-2.2/registration/backends/model_activation/__init__.py 0000644 0000767 0000767 00000000707 13007332734 026471 0 ustar james 0000000 0000000 """
A two-step (signup, then activation) registration workflow, using
a model to store the activation key.
To use, add 'registration' to your INSTALLED_APPS, run migrations and
include() the provided URLconf --
registration.backends.model_activation.urls -- somewhere in your URL
configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
https://django-registration.readthedocs.io/
"""
django-registration-2.2/registration/backends/model_activation/urls.py 0000644 0000767 0000767 00000002465 12726166473 025736 0 ustar james 0000000 0000000 """
URLconf for registration and activation, using django-registration's
two-step model-based activation workflow.
"""
from django.conf.urls import include, url
from django.views.generic.base import TemplateView
from . import views
urlpatterns = [
url(r'^activate/complete/$',
TemplateView.as_view(
template_name='registration/activation_complete.html'
),
name='registration_activation_complete'),
# Activation keys get matched by \w+ instead of the more specific
# [a-fA-F0-9]{40} because a bad activation key should still get to
# the view; that way it can return a sensible "invalid key"
# message instead of a confusing 404.
url(r'^activate/(?P\w+)/$',
views.ActivationView.as_view(),
name='registration_activate'),
url(r'^register/$',
views.RegistrationView.as_view(),
name='registration_register'),
url(r'^register/complete/$',
TemplateView.as_view(
template_name='registration/registration_complete.html'
),
name='registration_complete'),
url(r'^register/closed/$',
TemplateView.as_view(
template_name='registration/registration_closed.html'
),
name='registration_disallowed'),
url(r'', include('registration.auth_urls')),
]
django-registration-2.2/registration/backends/model_activation/views.py 0000644 0000767 0000767 00000003432 12614556316 026074 0 ustar james 0000000 0000000 """
A two-step (registration followed by activation) workflow, implemented
by storing an activation key in a model and emailing the key to the
user.
This workflow is provided primarily for backwards-compatibility with
existing installations; new installs of django-registration should
look into the HMAC activation workflow in registration.backends.hmac.
"""
from django.contrib.sites.shortcuts import get_current_site
from registration import signals
from registration.models import RegistrationProfile
from registration.views import ActivationView as BaseActivationView
from registration.views import RegistrationView as BaseRegistrationView
class RegistrationView(BaseRegistrationView):
"""
Register a new (inactive) user account, generate and store an
activation key, and email it to the user.
"""
def register(self, form):
new_user = RegistrationProfile.objects.create_inactive_user(
form,
site=get_current_site(self.request)
)
signals.user_registered.send(sender=self.__class__,
user=new_user,
request=self.request)
return new_user
def get_success_url(self, user):
return ('registration_complete', (), {})
class ActivationView(BaseActivationView):
"""
Given a valid activation key, activate the user's
account. Otherwise, show an error message stating the account
couldn't be activated.
"""
def activate(self, *args, **kwargs):
activation_key = kwargs.get('activation_key')
activated_user = RegistrationProfile.objects.activate_user(
activation_key
)
return activated_user
def get_success_url(self, user):
return ('registration_activation_complete', (), {})
django-registration-2.2/registration/backends/simple/ 0000755 0000767 0000767 00000000000 13011716531 022320 5 ustar james 0000000 0000000 django-registration-2.2/registration/backends/simple/__init__.py 0000644 0000767 0000767 00000000574 13007332734 024443 0 ustar james 0000000 0000000 """
A one-step registration workflow, in which a user signs up and is
immediately active and logged in.
To use, include() the provided URLconf --
registration.backends.simple.urls -- somewhere in your URL
configuration.
For more details, see the documentation in the docs/ directory of the
source-code distribution, or online at
https://django-registration.readthedocs.io/
"""
django-registration-2.2/registration/backends/simple/urls.py 0000644 0000767 0000767 00000001054 12726166473 023677 0 ustar james 0000000 0000000 """
URLconf for registration using django-registration's simple one-step
workflow.
"""
from django.conf.urls import include, url
from django.views.generic.base import TemplateView
from . import views
urlpatterns = [
url(r'^register/$',
views.RegistrationView.as_view(),
name='registration_register'),
url(r'^register/closed/$',
TemplateView.as_view(
template_name='registration/registration_closed.html'
),
name='registration_disallowed'),
url(r'', include('registration.auth_urls')),
]
django-registration-2.2/registration/backends/simple/views.py 0000644 0000767 0000767 00000002044 12614563136 024040 0 ustar james 0000000 0000000 """
A one-step (user signs up and is immediately active and logged in)
workflow.
"""
from django.contrib.auth import authenticate, get_user_model, login
from registration import signals
from registration.views import RegistrationView as BaseRegistrationView
User = get_user_model()
class RegistrationView(BaseRegistrationView):
"""
Registration via the simplest possible process: a user supplies a
username, email address and password (the bare minimum for a
useful account), and is immediately signed up and logged in).
"""
def register(self, form):
new_user = form.save()
new_user = authenticate(
username=getattr(new_user, User.USERNAME_FIELD),
password=form.cleaned_data['password1']
)
login(self.request, new_user)
signals.user_registered.send(sender=self.__class__,
user=new_user,
request=self.request)
return new_user
def get_success_url(self, user):
return '/'
django-registration-2.2/registration/forms.py 0000644 0000767 0000767 00000011635 12727400212 020762 0 ustar james 0000000 0000000 """
Forms and validation code for user registration.
Note that all of these forms assume your user model is similar in
structure to Django's default User class. If your user model is
significantly different, you may need to write your own form class;
see the documentation for notes on custom user models with
django-registration.
"""
from django import forms
from django.contrib.auth import get_user_model
from django.contrib.auth.forms import UserCreationForm
from django.core.exceptions import ValidationError
from django.utils.translation import ugettext_lazy as _
from . import validators
User = get_user_model()
class RegistrationForm(UserCreationForm):
"""
Form for registering a new user account.
Validates that the requested username is not already in use, and
requires the password to be entered twice to catch typos.
Subclasses should feel free to add any additional validation they
need, but should take care when overriding ``save()`` to respect
the ``commit=False`` argument, as several registration workflows
will make use of it to create inactive user accounts.
"""
# Explicitly declared here because Django's default
# UserCreationForm, which we subclass, does not require this field
# but workflows in django-registration which involve explicit
# activation step do require it. If you need an optional email
# field, simply subclass and declare the field not required.
email = forms.EmailField(
help_text=_(u'email address'),
required=True
)
class Meta(UserCreationForm.Meta):
fields = [
User.USERNAME_FIELD,
'email',
'password1',
'password2'
]
required_css_class = 'required'
def clean(self):
"""
Apply the reserved-name validator to the username.
"""
# This is done in clean() because Django does not currently
# have a non-ugly way to just add a validator to an existing
# field on a form when subclassing; the standard approach is
# to re-declare the entire field in order to specify the
# validator. That's not an option here because we're dealing
# with the user model and we don't know -- given custom users
# -- how to declare the username field.
#
# So defining clean() and attaching the error message (if
# there is one) to the username field is the least-ugly
# solution.
username_value = self.cleaned_data.get(User.USERNAME_FIELD)
if username_value is not None:
try:
if hasattr(self, 'reserved_names'):
reserved_names = self.reserved_names
else:
reserved_names = validators.DEFAULT_RESERVED_NAMES
validator = validators.ReservedNameValidator(
reserved_names=reserved_names
)
validator(username_value)
except ValidationError as v:
self.add_error(User.USERNAME_FIELD, v)
super(RegistrationForm, self).clean()
class RegistrationFormTermsOfService(RegistrationForm):
"""
Subclass of ``RegistrationForm`` which adds a required checkbox
for agreeing to a site's Terms of Service.
"""
tos = forms.BooleanField(
widget=forms.CheckboxInput,
label=_(u'I have read and agree to the Terms of Service'),
error_messages={
'required': validators.TOS_REQUIRED,
}
)
class RegistrationFormUniqueEmail(RegistrationForm):
"""
Subclass of ``RegistrationForm`` which enforces uniqueness of
email addresses.
"""
def clean_email(self):
"""
Validate that the supplied email address is unique for the
site.
"""
if User.objects.filter(email__iexact=self.cleaned_data['email']):
raise forms.ValidationError(validators.DUPLICATE_EMAIL)
return self.cleaned_data['email']
class RegistrationFormNoFreeEmail(RegistrationForm):
"""
Subclass of ``RegistrationForm`` which disallows registration with
email addresses from popular free webmail services; moderately
useful for preventing automated spam registrations.
To change the list of banned domains, pass a list of domains as
the keyword argument ``bad_domains`` when initializing the form.
"""
bad_domains = ['aim.com', 'aol.com', 'email.com', 'gmail.com',
'googlemail.com', 'hotmail.com', 'hushmail.com',
'msn.com', 'mail.ru', 'mailinator.com', 'live.com',
'yahoo.com']
def clean_email(self):
"""
Check the supplied email address against a list of known free
webmail domains.
"""
email_domain = self.cleaned_data['email'].split('@')[1]
if email_domain in self.bad_domains:
raise forms.ValidationError(validators.FREE_EMAIL)
return self.cleaned_data['email']
django-registration-2.2/registration/locale/ 0000755 0000767 0000767 00000000000 13011716531 020514 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/ar/ 0000755 0000767 0000767 00000000000 13011716531 021116 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/ar/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022703 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/ar/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000004127 12214057645 024516 0 ustar james 0000000 0000000 x - y _ N 6 V ; ' )
* 8 A R g } 5 C Q 1 l : @ + l , " ( 2 ?
I have read and agree to the Terms of Service Registration using free email addresses is prohibited. Please supply a different email address. This email address is already in use. Please supply a different email address. This username is already taken. Please choose another. Usernames can only contain letters, numbers and underscores You must agree to the terms to register You must type the same password each time activation key email address password password (again) registration profile registration profiles user username Project-Id-Version: PACKAGE VERSION
Report-Msgid-Bugs-To:
POT-Creation-Date: 2007-09-19 19:30-0500
PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE
Last-Translator: FULL NAME
Language-Team: LANGUAGE
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
أقر بقراءة والموافقة على شروط الخدمة يمنع التسجيل باستخدام عناوين بريد الكترونية مجانية. يرجى تزويد عنوان بريد الكتروني مختلف. عنوان البريد الالكتروني مسجل مسبقا. يرجى تزويد عنوان بريد الكتروني مختلف. اسم المستخدم مسجل مسبقا. يرجى اختيار اسم اخر. يمكن أن يحتوي اسم المستخدم على احرف، ارقام وشرطات سطرية فقط يجب الموافقة على الشروط للتسجيل يجب ادخال كلمة المرور مطابقة كل مرة رمز التفعيل عنوان البريد الالكتروني كلمة المرور تأكيد كلمة المرور ملف التسجيل الشخصي ملفات التسجيل الشخصية مستخدم اسم المستخدم django-registration-2.2/registration/locale/ar/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004743 12214057645 024525 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-09-19 19:30-0500\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: forms.py:38
msgid "username"
msgstr "اسم المستخدم"
#: forms.py:41
msgid "email address"
msgstr "عنوان البريد الالكتروني"
#: forms.py:43
msgid "password"
msgstr "كلمة المرور"
#: forms.py:45
msgid "password (again)"
msgstr "تأكيد كلمة المرور"
#: forms.py:54
msgid "Usernames can only contain letters, numbers and underscores"
msgstr "يمكن أن يحتوي اسم المستخدم على احرف، ارقام وشرطات سطرية فقط"
#: forms.py:59
msgid "This username is already taken. Please choose another."
msgstr "اسم المستخدم مسجل مسبقا. يرجى اختيار اسم اخر."
#: forms.py:68
msgid "You must type the same password each time"
msgstr "يجب ادخال كلمة المرور مطابقة كل مرة"
#: forms.py:96
msgid "I have read and agree to the Terms of Service"
msgstr "أقر بقراءة والموافقة على شروط الخدمة"
#: forms.py:105
msgid "You must agree to the terms to register"
msgstr "يجب الموافقة على الشروط للتسجيل"
#: forms.py:124
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr "عنوان البريد الالكتروني مسجل مسبقا. يرجى تزويد عنوان بريد الكتروني مختلف."
#: forms.py:149
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr "يمنع التسجيل باستخدام عناوين بريد الكترونية مجانية. يرجى تزويد عنوان بريد الكتروني مختلف."
#: models.py:188
msgid "user"
msgstr "مستخدم"
#: models.py:189
msgid "activation key"
msgstr "رمز التفعيل"
#: models.py:194
msgid "registration profile"
msgstr "ملف التسجيل الشخصي"
#: models.py:195
msgid "registration profiles"
msgstr "ملفات التسجيل الشخصية"
django-registration-2.2/registration/locale/bg/ 0000755 0000767 0000767 00000000000 13011716531 021104 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/bg/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022671 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/bg/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000004376 12214057645 024512 0 ustar james 0000000 0000000 x - y _ N 6 V ; ' )
* 8 A R g } s b b y Z { h _ ; % C P ) p + "
I have read and agree to the Terms of Service Registration using free email addresses is prohibited. Please supply a different email address. This email address is already in use. Please supply a different email address. This username is already taken. Please choose another. Usernames can only contain letters, numbers and underscores You must agree to the terms to register You must type the same password each time activation key email address password password (again) registration profile registration profiles user username Project-Id-Version: PACKAGE VERSION
Report-Msgid-Bugs-To:
POT-Creation-Date: 2007-09-19 19:30-0500
PO-Revision-Date: 2008-03-05 12:37+0200
Last-Translator: Vladislav
Language-Team: LANGUAGE
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Poedit-Bookmarks: -1,-1,-1,-1,10,-1,-1,-1,-1,-1
Прочел съм и съм съгласен с условията за експлоатация Регистрациите с безплатни адреси е забранен. Моля въведете различен адрес за електронна поща Адреса на електронната поща е използван. Моля въведете друг адрес. Потребителското име е заето. Моля изберето друго. Потребителските имена могат да съдържат букви, цифри и подчертавки Трябва да сте съгласни с условията за да се регистрирате. Грешка при проверка на паролата. Ключ за активация Електронна поща Парола Парола (проверка) регистрационен профил регистрационни профили Потребител Потребителско име django-registration-2.2/registration/locale/bg/LC_MESSAGES/django.po 0000644 0000767 0000767 00000005172 12214057645 024510 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-09-19 19:30-0500\n"
"PO-Revision-Date: 2008-03-05 12:37+0200\n"
"Last-Translator: Vladislav \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Bookmarks: -1,-1,-1,-1,10,-1,-1,-1,-1,-1\n"
#: forms.py:38
msgid "username"
msgstr "Потребителско име "
#: forms.py:41
msgid "email address"
msgstr "Електронна поща"
#: forms.py:43
msgid "password"
msgstr "Парола"
#: forms.py:45
msgid "password (again)"
msgstr "Парола (проверка)"
#: forms.py:54
msgid "Usernames can only contain letters, numbers and underscores"
msgstr "Потребителските имена могат да съдържат букви, цифри и подчертавки"
#: forms.py:59
msgid "This username is already taken. Please choose another."
msgstr "Потребителското име е заето. Моля изберето друго."
#: forms.py:68
msgid "You must type the same password each time"
msgstr "Грешка при проверка на паролата."
#: forms.py:96
msgid "I have read and agree to the Terms of Service"
msgstr "Прочел съм и съм съгласен с условията за експлоатация"
#: forms.py:105
msgid "You must agree to the terms to register"
msgstr "Трябва да сте съгласни с условията за да се регистрирате."
#: forms.py:124
msgid "This email address is already in use. Please supply a different email address."
msgstr "Адреса на електронната поща е използван. Моля въведете друг адрес."
#: forms.py:149
msgid "Registration using free email addresses is prohibited. Please supply a different email address."
msgstr "Регистрациите с безплатни адреси е забранен. Моля въведете различен адрес за електронна поща"
#: models.py:188
msgid "user"
msgstr "Потребител"
#: models.py:189
msgid "activation key"
msgstr "Ключ за активация"
#: models.py:194
msgid "registration profile"
msgstr "регистрационен профил"
#: models.py:195
msgid "registration profiles"
msgstr "регистрационни профили"
django-registration-2.2/registration/locale/ca/ 0000755 0000767 0000767 00000000000 13011716531 021077 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/ca/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022664 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/ca/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003641 12214057645 024477 0 ustar james 0000000 0000000 < ) - ( 9 _ S % N > ( g ' p j $ B g w 2 ~ ` , R P D > " a s
A user with that username already exists. Activate users E-mail I have read and agree to the Terms of Service Password Password (again) Re-send activation emails Registration using free email addresses is prohibited. Please supply a different email address. The two password fields didn't match. This email address is already in use. Please supply a different email address. This value must contain only letters, numbers and underscores. Username You must agree to the terms to register activation key registration profile registration profiles user Project-Id-Version: django-registration 0.8
Report-Msgid-Bugs-To:
POT-Creation-Date: 2011-07-17 11:04+0200
PO-Revision-Date: 2010-09-24 23:21+0100
Last-Translator: Carles Barrobés i Meix
Language-Team: Català
Language:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Poedit-Language: Catalan
Ja existeix un usuari amb aquest nom Activar usuaris E-mail He llegit i estic d'acord amb les condicions d'ús Contrasenya Contrasenya (de nou) Re-enviar e-mails d'activació Està prohibit registrar-se utilitzant adreces d'e-mail gratuïtes. Sisplau entreu-ne una altra. Els dos camps de contrasenya no coincideixen Aquesta adreça d'e-mail ja està sent utilitzada. Sisplau, entreu-ne una altra. Aquest valor ha de contenir només lletres, números i guions baixos Nom d'usuari Heu d'estar d'acord amb les condicions d'ús per registrar-vos clau d'activació perfil de registre perfils de registre usuari django-registration-2.2/registration/locale/ca/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004626 12214057645 024506 0 ustar james 0000000 0000000 # Catalan translation for django-registration.
# Copyright (C) 2007-2010, James Bennet
# This file is distributed under the same license as the django-registration package.
# Carles Barrobés , 2010.
#
msgid ""
msgstr ""
"Project-Id-Version: django-registration 0.8\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2011-07-17 11:04+0200\n"
"PO-Revision-Date: 2010-09-24 23:21+0100\n"
"Last-Translator: Carles Barrobés i Meix \n"
"Language-Team: Català\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Catalan\n"
#: admin.py:23
msgid "Activate users"
msgstr "Activar usuaris"
#: admin.py:43
msgid "Re-send activation emails"
msgstr "Re-enviar e-mails d'activació"
#: forms.py:35
msgid "Username"
msgstr "Nom d'usuari"
#: forms.py:36
msgid "This value must contain only letters, numbers and underscores."
msgstr "Aquest valor ha de contenir només lletres, números i guions baixos"
#: forms.py:39
msgid "E-mail"
msgstr "E-mail"
#: forms.py:41
msgid "Password"
msgstr "Contrasenya"
#: forms.py:43
msgid "Password (again)"
msgstr "Contrasenya (de nou)"
#: forms.py:55
msgid "A user with that username already exists."
msgstr "Ja existeix un usuari amb aquest nom"
#: forms.py:67
msgid "The two password fields didn't match."
msgstr "Els dos camps de contrasenya no coincideixen"
#: forms.py:78
msgid "I have read and agree to the Terms of Service"
msgstr "He llegit i estic d'acord amb les condicions d'ús"
#: forms.py:79
msgid "You must agree to the terms to register"
msgstr "Heu d'estar d'acord amb les condicions d'ús per registrar-vos"
#: forms.py:95
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"Aquesta adreça d'e-mail ja està sent utilitzada. Sisplau, entreu-ne una "
"altra."
#: forms.py:122
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"Està prohibit registrar-se utilitzant adreces d'e-mail gratuïtes. Sisplau "
"entreu-ne una altra."
#: models.py:168
msgid "user"
msgstr "usuari"
#: models.py:169
msgid "activation key"
msgstr "clau d'activació"
#: models.py:174
msgid "registration profile"
msgstr "perfil de registre"
#: models.py:175
msgid "registration profiles"
msgstr "perfils de registre"
#~ msgid "Email address"
#~ msgstr "Adreça d'e-mail"
django-registration-2.2/registration/locale/cs/ 0000755 0000767 0000767 00000000000 13011716531 021121 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/cs/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022706 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/cs/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003653 12214057645 024524 0 ustar james 0000000 0000000 < )
- & / @ _ Z % N > / ' n Q ) 0 Z o 4
! a N S m E F N a v
A user with that username already exists. Activate users Email address I have read and agree to the Terms of Service Password Password (again) Re-send activation emails Registration using free email addresses is prohibited. Please supply a different email address. The two password fields didn't match. This email address is already in use. Please supply a different email address. This value must contain only letters, numbers and underscores. You must agree to the terms to register activation key registration profile registration profiles user username Project-Id-Version: PACKAGE VERSION
Report-Msgid-Bugs-To:
POT-Creation-Date: 2009-10-12 14:09-0500
PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE
Last-Translator: Implayo s.r.o.
Language-Team: LANGUAGE
Language: cs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Uživatel s tímto jménem již existuje. Aktivovat uživatele E-mailová adresa Přečetl jsem si a souhlasím s podmínkami služby Heslo Heslo (znovu) Znovu odeslat aktivační e-maily Používání volných e-mailových adres je zakázáno. Prosím zadejte jinou e-mailovou adresu. Zadaná 2 hesla se neshodují. Tato e-mailová adresa se již používá. Prosím zadejte jinou e-mailovou adresu. Tato hodnota může obsahovat pouze písmena, čísla a podtržítka. Musíte odsouhlasit podmínky služby pro pokračování v registraci. aktivační klíč registrační profil registrační profily uživatel uživatelské jméno django-registration-2.2/registration/locale/cs/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004531 12214057645 024523 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , 2011.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-10-12 14:09-0500\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Implayo s.r.o. \n"
"Language-Team: LANGUAGE \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: admin.py:23
msgid "Activate users"
msgstr "Aktivovat uživatele"
#: admin.py:43
msgid "Re-send activation emails"
msgstr "Znovu odeslat aktivační e-maily"
#: forms.py:35
msgid "username"
msgstr "uživatelské jméno"
#: forms.py:36
msgid "This value must contain only letters, numbers and underscores."
msgstr "Tato hodnota může obsahovat pouze písmena, čísla a podtržítka."
#: forms.py:39
msgid "Email address"
msgstr "E-mailová adresa"
#: forms.py:41
msgid "Password"
msgstr "Heslo"
#: forms.py:43
msgid "Password (again)"
msgstr "Heslo (znovu)"
#: forms.py:55
msgid "A user with that username already exists."
msgstr "Uživatel s tímto jménem již existuje."
#: forms.py:67
msgid "The two password fields didn't match."
msgstr "Zadaná 2 hesla se neshodují."
#: forms.py:78
msgid "I have read and agree to the Terms of Service"
msgstr "Přečetl jsem si a souhlasím s podmínkami služby"
#: forms.py:79
msgid "You must agree to the terms to register"
msgstr "Musíte odsouhlasit podmínky služby pro pokračování v registraci."
#: forms.py:95
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"Tato e-mailová adresa se již používá. Prosím zadejte jinou e-mailovou "
"adresu."
#: forms.py:122
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"Používání volných e-mailových adres je zakázáno. Prosím zadejte "
"jinou e-mailovou adresu."
#: models.py:165
msgid "user"
msgstr "uživatel"
#: models.py:166
msgid "activation key"
msgstr "aktivační klíč"
#: models.py:171
msgid "registration profile"
msgstr "registrační profil"
#: models.py:172
msgid "registration profiles"
msgstr "registrační profily"
django-registration-2.2/registration/locale/da/ 0000755 0000767 0000767 00000000000 13011716531 021100 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/da/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022665 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/da/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003413 12214057645 024475 0 ustar james 0000000 0000000 < )
- & / @ _ Z % N > / n ' w 3
+ ( 9 b k } Z @ 8 T
0
A user with that username already exists. Activate users Email address I have read and agree to the Terms of Service Password Password (again) Re-send activation emails Registration using free email addresses is prohibited. Please supply a different email address. The two password fields didn't match. This email address is already in use. Please supply a different email address. This value must contain only letters, numbers and underscores. Username You must agree to the terms to register activation key registration profile registration profiles user Project-Id-Version: django-registration 0.8
Report-Msgid-Bugs-To:
POT-Creation-Date:
PO-Revision-Date:
Last-Translator: Rune Bromer
Language-Team:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Der findes allerede en bruger med dette brugernavn. Aktiver brugere E-mailadresse I har l¾st og accepterer betingelserne. Password Password (gentag) Gensend aktiveringsemails Registrering med gratis emailadresser er ikke muligt. V¾lg venligst en anden emailadresse De 2 passwordfelter er ikke ens. Denne emailadresse er allerede i brug. Benyt venligst en anden. V¾rdien m kun indeholde bogstaver, tal og underscore. Brugernavn Du skal acceptere betingelserne for at registere Aktiveringsn¿gle Registreringsprofil Registreringprofiler bruger django-registration-2.2/registration/locale/da/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004264 12214057645 024505 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Rune Bromer , 2007-2009.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: django-registration 0.8 \n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: \n"
"PO-Revision-Date: \n"
"Last-Translator: Rune Bromer \n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: admin.py:23
msgid "Activate users"
msgstr "Aktiver brugere"
#: admin.py:43
msgid "Re-send activation emails"
msgstr "Gensend aktiveringsemails"
#: forms.py:35
msgid "Username"
msgstr "Brugernavn"
#: forms.py:36
msgid "This value must contain only letters, numbers and underscores."
msgstr "V¾rdien m kun indeholde bogstaver, tal og underscore."
#: forms.py:39
msgid "Email address"
msgstr "E-mailadresse"
#: forms.py:41
msgid "Password"
msgstr "Password"
#: forms.py:43
msgid "Password (again)"
msgstr "Password (gentag)"
#: forms.py:55
msgid "A user with that username already exists."
msgstr "Der findes allerede en bruger med dette brugernavn."
#: forms.py:67
msgid "The two password fields didn't match."
msgstr "De 2 passwordfelter er ikke ens."
#: forms.py:78
msgid "I have read and agree to the Terms of Service"
msgstr "I har l¾st og accepterer betingelserne."
#: forms.py:79
msgid "You must agree to the terms to register"
msgstr "Du skal acceptere betingelserne for at registere"
#: forms.py:95
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"Denne emailadresse er allerede i brug. Benyt venligst en anden. "
#: forms.py:122
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"Registrering med gratis emailadresser er ikke muligt. V¾lg venligst en "
"anden emailadresse"
#: models.py:165
msgid "user"
msgstr "bruger"
#: models.py:166
msgid "activation key"
msgstr "Aktiveringsn¿gle"
#: models.py:171
msgid "registration profile"
msgstr "Registreringsprofil"
#: models.py:172
msgid "registration profiles"
msgstr "Registreringprofiler"
django-registration-2.2/registration/locale/de/ 0000755 0000767 0000767 00000000000 13011716531 021104 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/de/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022671 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/de/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003717 12214057645 024510 0 ustar james 0000000 0000000 < )
- & / @ _ Z % N > / n ' w F ) % O c ; r ! t , e W D / G <
A user with that username already exists. Activate users Email address I have read and agree to the Terms of Service Password Password (again) Re-send activation emails Registration using free email addresses is prohibited. Please supply a different email address. The two password fields didn't match. This email address is already in use. Please supply a different email address. This value must contain only letters, numbers and underscores. Username You must agree to the terms to register activation key registration profile registration profiles user Project-Id-Version: django-registration 0.8
Report-Msgid-Bugs-To:
POT-Creation-Date: 2009-10-18 21:32+0200
PO-Revision-Date: 2007-09-29 16:50+0200
Last-Translator: Jannis Leidel
Language-Team: Deutsch
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Dieser Benutzername ist bereits vergeben. Benutzer aktivieren E-Mail-Adresse Ich habe die Nutzungsvereinbarung gelesen und stimme ihr zu Passwort Passwort (wiederholen) Aktivierungs-E-Mail erneut senden Die Registrierung mit einer kostenlosen E-Mail-Adresse ist untersagt. Bitte geben Sie eine andere E-Mail-Adresse an. Die beiden Passwörter sind nicht identisch. Diese E-Mail-Adresse wird schon genutzt. Bitte geben Sie eine andere E-Mail-Adresse an. Dieser Wert darf nur Buchstaben, Ziffern und Unterstriche enthalten. Benutzername Sie müssen der Nutzungsvereinbarung zustimmen, um sich zu registrieren Aktivierungsschlüssel Registrierungsprofil Registrierungsprofile Benutzer django-registration-2.2/registration/locale/de/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004572 12214057645 024513 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Jannis Leidel , 2007-2009.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: django-registration 0.8 \n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-10-18 21:32+0200\n"
"PO-Revision-Date: 2007-09-29 16:50+0200\n"
"Last-Translator: Jannis Leidel \n"
"Language-Team: Deutsch \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: admin.py:23
msgid "Activate users"
msgstr "Benutzer aktivieren"
#: admin.py:43
msgid "Re-send activation emails"
msgstr "Aktivierungs-E-Mail erneut senden"
#: forms.py:35
msgid "Username"
msgstr "Benutzername"
#: forms.py:36
msgid "This value must contain only letters, numbers and underscores."
msgstr "Dieser Wert darf nur Buchstaben, Ziffern und Unterstriche enthalten."
#: forms.py:39
msgid "Email address"
msgstr "E-Mail-Adresse"
#: forms.py:41
msgid "Password"
msgstr "Passwort"
#: forms.py:43
msgid "Password (again)"
msgstr "Passwort (wiederholen)"
#: forms.py:55
msgid "A user with that username already exists."
msgstr "Dieser Benutzername ist bereits vergeben."
#: forms.py:67
msgid "The two password fields didn't match."
msgstr "Die beiden Passwörter sind nicht identisch."
#: forms.py:78
msgid "I have read and agree to the Terms of Service"
msgstr "Ich habe die Nutzungsvereinbarung gelesen und stimme ihr zu"
#: forms.py:79
msgid "You must agree to the terms to register"
msgstr "Sie müssen der Nutzungsvereinbarung zustimmen, um sich zu registrieren"
#: forms.py:95
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"Diese E-Mail-Adresse wird schon genutzt. Bitte geben Sie eine andere E-Mail-"
"Adresse an."
#: forms.py:122
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"Die Registrierung mit einer kostenlosen E-Mail-Adresse ist untersagt. Bitte "
"geben Sie eine andere E-Mail-Adresse an."
#: models.py:165
msgid "user"
msgstr "Benutzer"
#: models.py:166
msgid "activation key"
msgstr "Aktivierungsschlüssel"
#: models.py:171
msgid "registration profile"
msgstr "Registrierungsprofil"
#: models.py:172
msgid "registration profiles"
msgstr "Registrierungsprofile"
django-registration-2.2/registration/locale/el/ 0000755 0000767 0000767 00000000000 13011716531 021114 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/el/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022701 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/el/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000004570 12214057645 024516 0 ustar james 0000000 0000000 x - y _ N 6 V ; ' )
* 8 A R g } 5 W b Y ' o D ! 3 Q `
I have read and agree to the Terms of Service Registration using free email addresses is prohibited. Please supply a different email address. This email address is already in use. Please supply a different email address. This username is already taken. Please choose another. Usernames can only contain letters, numbers and underscores You must agree to the terms to register You must type the same password each time activation key email address password password (again) registration profile registration profiles user username Project-Id-Version: PACKAGE VERSION
Report-Msgid-Bugs-To:
POT-Creation-Date: 2007-09-19 19:30-0500
PO-Revision-Date: 2007-11-14 21:50+0200
Last-Translator: FULL NAME
Language-Team: LANGUAGE
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Διάβασα και συμφωνώ με τους Όρους της Υπηρεσίας Η εγγραφή μέσω δωρεάν διευθύνσεων ηλεκτρονικού ταχυδρομείου απαγορεύεται. Παρακαλώ δώστε κάποια άλλη. Η συγκεκριμένη διεύθυνση ηλεκτρονικού ταχυδρομείου χρησιμοποιείται ήδη. Παρακαλώ δώστε κάποια άλλη. Αυτό το όνομα χρήστη χρησιμοποίειται ήδη. Παρακαλώ διαλέξτε ένα άλλο. Τα ονόματα χρηστών μπορούν να περιλαμβάνουν μόνο γράμματα, αριθμούς και υπογραμμίσεις Πρέπει να συμφωνείται με τους όρους για να εγγραφείτε Πρέπει να εισάγετε το ίδιο συνθηματικό κάθε φορά κλειδί ενεργοποίησης διεύθυνση ηλεκτρονικού ταχυδρομείου συνθηματικό συνθηματικό (ξανά) προφίλ εγγραφής προφίλ εγγραφών χρήστης όνομα χρήστη django-registration-2.2/registration/locale/el/LC_MESSAGES/django.po 0000644 0000767 0000767 00000005436 12214057645 024523 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Panos Laganakos , 2007.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-09-19 19:30-0500\n"
"PO-Revision-Date: 2007-11-14 21:50+0200\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: forms.py:38
msgid "username"
msgstr "όνομα χρήστη"
#: forms.py:41
msgid "email address"
msgstr "διεύθυνση ηλεκτρονικού ταχυδρομείου"
#: forms.py:43
msgid "password"
msgstr "συνθηματικό"
#: forms.py:45
msgid "password (again)"
msgstr "συνθηματικό (ξανά)"
#: forms.py:54
msgid "Usernames can only contain letters, numbers and underscores"
msgstr "Τα ονόματα χρηστών μπορούν να περιλαμβάνουν μόνο γράμματα, αριθμούς και υπογραμμίσεις"
#: forms.py:59
msgid "This username is already taken. Please choose another."
msgstr "Αυτό το όνομα χρήστη χρησιμοποίειται ήδη. Παρακαλώ διαλέξτε ένα άλλο."
#: forms.py:68
msgid "You must type the same password each time"
msgstr "Πρέπει να εισάγετε το ίδιο συνθηματικό κάθε φορά"
#: forms.py:96
msgid "I have read and agree to the Terms of Service"
msgstr "Διάβασα και συμφωνώ με τους Όρους της Υπηρεσίας"
#: forms.py:105
msgid "You must agree to the terms to register"
msgstr "Πρέπει να συμφωνείται με τους όρους για να εγγραφείτε"
#: forms.py:124
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"Η συγκεκριμένη διεύθυνση ηλεκτρονικού ταχυδρομείου χρησιμοποιείται ήδη. "
"Παρακαλώ δώστε κάποια άλλη."
#: forms.py:149
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"Η εγγραφή μέσω δωρεάν διευθύνσεων ηλεκτρονικού ταχυδρομείου απαγορεύεται. ""Παρακαλώ δώστε κάποια άλλη."
#: models.py:188
msgid "user"
msgstr "χρήστης"
#: models.py:189
msgid "activation key"
msgstr "κλειδί ενεργοποίησης"
#: models.py:194
msgid "registration profile"
msgstr "προφίλ εγγραφής"
#: models.py:195
msgid "registration profiles"
msgstr "προφίλ εγγραφών"
django-registration-2.2/registration/locale/en/ 0000755 0000767 0000767 00000000000 13011716531 021116 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/en/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022703 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/en/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000000557 12214057645 024521 0 ustar james 0000000 0000000 $ , 8 5 9 Project-Id-Version: PACKAGE VERSION
Report-Msgid-Bugs-To:
POT-Creation-Date: 2009-10-12 14:09-0500
PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE
Last-Translator: FULL NAME
Language-Team: LANGUAGE
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
django-registration-2.2/registration/locale/en/LC_MESSAGES/django.po 0000644 0000767 0000767 00000003271 12214057645 024520 0 ustar james 0000000 0000000 # SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-10-12 14:09-0500\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: admin.py:23
msgid "Activate users"
msgstr ""
#: admin.py:43
msgid "Re-send activation emails"
msgstr ""
#: forms.py:35
msgid "username"
msgstr ""
#: forms.py:36
msgid "This value must contain only letters, numbers and underscores."
msgstr ""
#: forms.py:39
msgid "Email address"
msgstr ""
#: forms.py:41
msgid "Password"
msgstr ""
#: forms.py:43
msgid "Password (again)"
msgstr ""
#: forms.py:55
msgid "A user with that username already exists."
msgstr ""
#: forms.py:67
msgid "The two password fields didn't match."
msgstr ""
#: forms.py:78
msgid "I have read and agree to the Terms of Service"
msgstr ""
#: forms.py:79
msgid "You must agree to the terms to register"
msgstr ""
#: forms.py:95
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
#: forms.py:122
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
#: models.py:165
msgid "user"
msgstr ""
#: models.py:166
msgid "activation key"
msgstr ""
#: models.py:171
msgid "registration profile"
msgstr ""
#: models.py:172
msgid "registration profiles"
msgstr ""
django-registration-2.2/registration/locale/es/ 0000755 0000767 0000767 00000000000 13011716531 021123 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/es/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 022710 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/es/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003565 12214057645 024530 0 ustar james 0000000 0000000 x - y _ N 6 V ; ' )
* 8 A R g } T , v
a > N % 1 t 3 3 F [ c
I have read and agree to the Terms of Service Registration using free email addresses is prohibited. Please supply a different email address. This email address is already in use. Please supply a different email address. This username is already taken. Please choose another. Usernames can only contain letters, numbers and underscores You must agree to the terms to register You must type the same password each time activation key email address password password (again) registration profile registration profiles user username Project-Id-Version: django-registration 0.3
Report-Msgid-Bugs-To:
POT-Creation-Date: 2008-03-11 00:19-0400
PO-Revision-Date: 2008-03-11 00:19-0400
Last-Translator: Ernesto Rico Schmidt
Language-Team: Español
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
He leído y acepto los términos de servicio El registro usando una dirección de correo electrónico gratis está prohibido.Por favor proporciona otra dirección. La dirección de correo electrónico ya está siendo usada. Por favorproporciona otra dirección. Este nombre de usuario ya está ocupado. Por favor escoge otro Los nombres de usuarios sólo pueden contener letras, números y guiones bajos Tienes que aceptar los términos para registrarte Tienes que introducir la misma contraseña cada vez clave de activación dirección de coreo electrónico contraseña contraseña (otra vez) perfil de registro perfiles de registro usuario nombre de usuario django-registration-2.2/registration/locale/es/LC_MESSAGES/django.po 0000644 0000767 0000767 00000004452 12214057645 024527 0 ustar james 0000000 0000000 # Spanish translation for django-registration.
# Copyright (C) 2007, James Bennet
# This file is distributed under the same license as the registration package.
# Ernesto Rico Schmidt , 2008.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: django-registration 0.3 \n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2008-03-11 00:19-0400\n"
"PO-Revision-Date: 2008-03-11 00:19-0400\n"
"Last-Translator: Ernesto Rico Schmidt \n"
"Language-Team: Español \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: forms.py:38
msgid "username"
msgstr "nombre de usuario"
#: forms.py:41
msgid "email address"
msgstr "dirección de coreo electrónico"
#: forms.py:43
msgid "password"
msgstr "contraseña"
#: forms.py:45
msgid "password (again)"
msgstr "contraseña (otra vez)"
#: forms.py:54
msgid "Usernames can only contain letters, numbers and underscores"
msgstr "Los nombres de usuarios sólo pueden contener letras, números y guiones bajos"
#: forms.py:59
msgid "This username is already taken. Please choose another."
msgstr "Este nombre de usuario ya está ocupado. Por favor escoge otro"
#: forms.py:71
msgid "You must type the same password each time"
msgstr "Tienes que introducir la misma contraseña cada vez"
#: forms.py:100
msgid "I have read and agree to the Terms of Service"
msgstr "He leído y acepto los términos de servicio"
#: forms.py:109
msgid "You must agree to the terms to register"
msgstr "Tienes que aceptar los términos para registrarte"
#: forms.py:128
msgid ""
"This email address is already in use. Please supply a different email "
"address."
msgstr ""
"La dirección de correo electrónico ya está siendo usada. Por favor"
"proporciona otra dirección."
#: forms.py:153
msgid ""
"Registration using free email addresses is prohibited. Please supply a "
"different email address."
msgstr ""
"El registro usando una dirección de correo electrónico gratis está prohibido."
"Por favor proporciona otra dirección."
#: models.py:188
msgid "user"
msgstr "usuario"
#: models.py:189
msgid "activation key"
msgstr "clave de activación"
#: models.py:194
msgid "registration profile"
msgstr "perfil de registro"
#: models.py:195
msgid "registration profiles"
msgstr "perfiles de registro"
django-registration-2.2/registration/locale/es_AR/ 0000755 0000767 0000767 00000000000 13011716531 021505 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/es_AR/LC_MESSAGES/ 0000755 0000767 0000767 00000000000 13011716531 023272 5 ustar james 0000000 0000000 django-registration-2.2/registration/locale/es_AR/LC_MESSAGES/django.mo 0000644 0000767 0000767 00000003471 12214057645 025106 0 ustar james 0000000 0000000 x - y _ N 6 V ; ' )
* 8 A R g } 5 <