Django-registration

Latest version: v5.1.0

Safety actively analyzes 685525 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 2

5.1.0

~~~~~~~~~~~~~

Released November 2024

* Adopted "DjangoVer" versioning.

* Supported Django versions are now 4.2, 5.0, and 5.1.

* Supported Python versions are now 3.9, 3.10, 3.11, 3.12, and 3.13.

* The base :class:`~django_registration.forms.RegistrationForm` has been
completely rewritten, though in a backwards-compatible way. It is no longer a
subclass of Django's ``UserCreationForm``, which means it is far more
flexible with respect to custom user models (and for many cases, no longer
requires a custom form subclass just to handle a custom user model).

* :class:`~django_registration.views.ActivationView` has also been rewritten,
and with it parts of :ref:`the built-in activation-based workflow
<activation-workflow>`. The primary change here is that ``ActivationView``
now only attempts to activate the user account on an HTTP ``POST`` request
(previously it would do so on ``GET``, which was increasingly unsafe due to
email clients auto-following links). This is backwards-incompatible: the
activation view now displays a form on ``GET``, and the templates involved
have changed. See :ref:`the template documentation <default-templates>` for
details of the required templates.


Releases preceding DjangoVer
----------------------------

5.0

Django 5.0 (after 5.0.0 and 5.0.1). Since the Django project at the time was
supporting Django 5.0 and 4.2, that version of ``django-registration`` would
also support Django 5.0 and 4.2.


API stability and deprecations
------------------------------

The API stability/deprecation policy for ``django-registration`` is as follows:

* The supported stable public API is the set of symbols which are documented in
this documentation. For classes, the supported stable public API is the set
of methods and attributes of those classes whose names do not begin with one
or more underscore (``_``) characters and which are documented in this
documentation.

* When a public API is to be removed, or undergo a backwards-incompatible
change, it will emit a deprecation warning which serves as notice of the
intended removal or change. This warning will be emitted for at least two
releases, after which the removal or change may occur without further
warning. This is different from Django's own deprecation policy, which avoids
completing a removal/change in "LTS"-designated releases. Since
``django-registration`` does not have "LTS" releases, it does not need that
exception.

* Security fixes, and fixes for high-severity bugs (such as those which might
cause unrecoverable crash or data loss), are not required to emit deprecation
warnings, and may -- if needed -- impose backwards-incompatible change in any
release. If this occurs, this changelog document will contain a note
explaining why the usual deprecation process could not be followed for that
case.

* This policy is in effect as of the adoption of "DjangoVer" versioning, with
version 5.0.0 of ``django-registration``.


Releases under DjangoVer
------------------------

3.4

~~~~~~~~~~~

Released July 2023

* The :ref:`reserved names list <reserved-names>` has a new entry: ``"xrpc"``,
which is used in domain-ownership verification by Bluesky/AT protocol.

* Validation of the email field in registration forms no longer applies
Django's default email validator, instead applying only ``django-registration``'s
:class:`~django_registration.validators.HTML5EmailValidator` and
:func:`~django_registration.validators.validate_confusables_email`. Since
``django-registration``'s validators are significantly stricter, this does not
actually change the set of email addresses which will be accepted; all it
does is prevent a duplicate error message displaying when both the default
Django validator and the ``django-registration`` validators reject the email
address. See `GitHub issue 238
<https://github.com/ubernostrum/django-registration/issues/238>`_.

* The supported Python and Django versions are changed to: Django 3.2, 4.1, and
4.2, on Python 3.7 (Django 3.2 only), 3.8, 3.9, 3.10, and 3.11 (Django 4.1
and 4.2 only).

3.3

~~~~~~~~~~~

Released May 2022

This release contains no new features or bugfixes. The supported Python and
Django versions are changed to:

* Django 3.2 and 4.0, on Python 3.7 (Django 3.2 only), 3.8, 3.9, and 3.10.

3.2

~~~~~~~~~~~

Released June 2021

This release contains no new features or bugfixes. The supported Python and
Django versions are changed to:

* Django 2.2, 3.1, and 3.2, on Python 3.6, 3.7, 3.8, and 3.9.

Python 3.5 reached the end of its upstream support cycle in September 2020, and
is no longer supported. Django 3.0 reached the end of its upstream support
cycle in May 2021, and is no longer supported.

3.1.2

~~~~~~~~~~~~~

Released March 2021

This release fixes a security issue with low severity.

Prior to 3.1.2, ``django-registration`` did not apply Django's
:func:`~django.views.decorators.debug.sensitive_post_parameters` decorator to
the base :class:`~django_registration.views.RegistrationView`. This meant that
if detailed error reports, such as `Django's error reports emailed to site
staff
<https://docs.djangoproject.com/en/3.1/howto/error-reporting/#email-reports>`_,
were enabled, and a server-side error occurred during account registration, the
generated error report would include all fields submitted in the HTTP request,
some of which are potentially sensitive depending on the user-account model and
registration workflow in use.

This issue is CVE-2021-21416 and GitHub security advisory GHSA-58c7-px5v-82hh.

Thanks to Martin Morgenstern for reporting this issue.

Page 1 of 2

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.