Path to this page:
Subject: CVS commit: pkgsrc/www/py-django-allauth
From: Adam Ciarcinski
Date: 2023-12-02 08:26:21
Message id: 20231202072621.34F6DFA40@cvs.NetBSD.org
Log Message:
py-django-allauth: updated to 0.58.2
0.58.0 (2023-10-26)
*******************
Note worthy changes
-------------------
- The ``SocialAccount.exra_data`` field was a custom JSON field that used
``TextField`` as the underlying implementation. It was once needed because
Django had no ``JSONField`` support. Now, this field is changed to use the
official ``JSONField()``. Migrations are in place.
- Officially support Django 5.0.
- In previous versions, users could never remove their primary email address.
This is constraint is now relaxed. In case the email address is not required,
for example, because the user logs in by username, removal of the email
address is allowed.
- Added a new setting ``ACCOUNT_REAUTHENTICATION_REQUIRED`` that, when enabled,
requires the user to reauthenticate before changes (such as changing the
primary email address, adding a new email address, etc.) can be performed.
Backwards incompatible changes
------------------------------
- Refactored the built-in templates, with the goal of being able to adjust the
look and feel of the whole project by only overriding a few core templates.
This approach allows you to achieve visual results fast, but is of course more
limited compared to styling all templates yourself. If your project provided
its own templates then this change will not affect anything, but if you rely
on (some of) the built-in templates your project may be affected.
- The Azure provider has been removed in favor of keeping the Microsoft
provider. Both providers were targeting the same goal.
Security notice
---------------
- Facebook: Using the JS SDK flow, it was possible to post valid access tokens
originating from other apps. Facebook user IDs are scoped per app. By default
that user ID (not the email address) is used as key while
authenticating. Therefore, such access tokens can not be abused by
default. However, in case ``SOCIALACCOUNT_EMAIL_AUTHENTICATION`` was
explicitly enabled for the Facebook provider, these tokens could be used to
login.
0.57.0 (2023-09-24)
*******************
Note worthy changes
-------------------
- Added Django password validation help text to ``password1`` on
set/change/signup forms.
- Microsoft: the tenant parameter can now be configured per app.
- SAML: Added support for additional configuration parameters, such as contacts,
and support for certificate rotation.
- The enumeration prevention behavior at signup is now configurable. Whether or
not enumeration can be prevented during signup depends on the email
verification method. In case of mandatory verification, enumeration can be
properly prevented because the case where an email address is already taken is
indistinguishable from the case where it is not. However, in case of optional
or disabled email verification, enumeration can only be prevented by allowing
the signup to go through, resulting in multiple accounts sharing same email
address (although only one of the accounts can ever have it verified). When
enumeration is set to ``True``, email address uniqueness takes precedence over
enumeration prevention, and the issue of multiple accounts having the same
email address will be avoided, thus leaking information. Set it to
``"strict"`` to allow for signups to go through.
Fixes
=====
- Fixed ``?next=`` URL handling in the SAML provider.
- During 2FA, pending logins were incorrectly removed when e.g. Django was asked
to serve a ``/favicon.ico`` URL.
Files: