Django-allauth

*******************

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.

*******************

Security notice
---------------

- ``ImmediateHttpResponse`` exceptions were not handled properly when raised
inside ``adapter.pre_login()``. If you relied on aborting the login using
this mechanism, that would not work. Most notably, django-allauth-2fa uses
this approach, resulting in 2FA not being triggered.

*******************

Note worthy changes
-------------------

- Added builtin support for Two-Factor Authentication via the ``allauth.mfa`` app.

- The fact that ``request`` is not available globally has left its mark on the
code over the years. Some functions get explicitly passed a request, some do
not, and some constructs have it available both as a parameter and as
``self.request``. As having request available is essential, especially when
trying to implement adapter hooks, the request has now been made globally
available via::

from allauth.core import context
context.request

- Previously, ``SOCIALACCOUNT_STORE_TOKENS = True`` did not work when the social
app was configured in the settings instead of in the database. Now, this
functionality works regardless of how you configure the app.


Backwards incompatible changes
------------------------------

- Dropped support for Django 3.1.

- The ``"allauth.account.middleware.AccountMiddleware"`` middleware is required
to be present in your ``settings.MIDDLEWARE``.

- Starting from September 1st 2023, CERN upgraded their SSO to a standard OpenID
Connect based solution. As a result, the previously builtin CERN provider is
no longer needed and has been removed. Instead, use the regular OpenID Connect
configuration::

SOCIALACCOUNT_PROVIDERS = {
"openid_connect": {
"APPS": [
{
"provider_id": "cern",
"name": "CERN",
"client_id": "<insert-id>",
"secret": "<insert-secret>",
"settings": {
"server_url": "https://auth.cern.ch/auth/realms/cern/.well-known/openid-configuration",
},
}
]
}
}

- The Keycloak provider was added before the OpenID Connect functionality
landed. Afterwards, the Keycloak implementation was refactored to reuse the
regular OIDC provider. As this approach led to bugs (see 0.55.1), it was
decided to remove the Keycloak implementation altogether. Instead, use the
regular OpenID Connect configuration::

SOCIALACCOUNT_PROVIDERS = {
"openid_connect": {
"APPS": [
{
"provider_id": "keycloak",
"name": "Keycloak",
"client_id": "<insert-id>",
"secret": "<insert-secret>",
"settings": {
"server_url": "http://keycloak:8080/realms/master/.well-known/openid-configuration",
},
}
]
}
}

*******************

Fixes
-----

- Email confirmation: An attribute error could occur when following invalid
email confirmation links.

*******************

Fixes
-----

- SAML: the lookup of the app (``SocialApp``) was working correctly for apps
configured via the settings, but failed when the app was configured via the
Django admin.

- Keycloak: fixed reversal of the callback URL, which was reversed using
``"openid_connect_callback"`` instead of ``"keycloak_callback"``. Although the
resulting URL is the same, it results in a ``NoReverseMatch`` error when
``allauth.socialaccount.providers.openid_connect`` is not present in
``INSTALLED_APPS``.

*******************

Note worthy changes
-------------------

- Introduced a new setting ``ACCOUNT_PASSWORD_RESET_TOKEN_GENERATOR`` that
allows you to specify the token generator for password resets.

- Dropped support for Django 2.x and 3.0.

- Officially support Django 4.2.

- New providers: Miro, Questrade

- It is now possible to manage OpenID Connect providers via the Django
admin. Simply add a `SocialApp` for each OpenID Connect provider.

- There is now a new flow for changing the email address. When enabled
(``ACCOUNT_CHANGE_EMAIL``), users are limited to having exactly one email
address that they can change by adding a temporary second email address that,
when verified, replaces the current email address.

- Changed spelling from "e-mail" to "email". Both are correct, however, the
trend over the years has been towards the simpler and more streamlined form
"email".

- Added support for SAML 2.0. Thanks to `Dskrpt <https://dskrpt.de>`_
for sponsoring the development of this feature!

- Fixed Twitter OAuth2 authentication by using basic auth and adding scope `tweet.read`.

- Added (optional) support for authentication by email for social logins (see
``SOCIALACCOUNT_EMAIL_AUTHENTICATION``).


Security notice
---------------

- Even with account enumeration prevention in place, it was possible for a user
to infer whether or not a given account exists based by trying to add
secondary email addresses . This has been fixed -- see the note on backwards
incompatible changes.


Backwards incompatible changes
------------------------------

- Data model changes: when ``ACCOUNT_UNIQUE_EMAIL=True`` (the default), there
was a unique constraint on set on the ``email`` field of the ``EmailAddress``
model. This constraint has been relaxed, now there is a unique constraint on
the combination of ``email`` and ``verified=True``. Migrations are in place to
automatically transition, but if you have a lot of accounts, you may need to
take special care using ``CREATE INDEX CONCURRENTLY``.

- The method ``allauth.utils.email_address_exists()`` has been removed.

- The Mozilla Persona provider has been removed. The project was shut down on
November 30th 2016.

- A large internal refactor has been performed to be able to add support for
providers oferring one or more subproviders. This refactor has the following
impact:

- The provider registry methods ``get_list()``, ``by_id()`` have been
removed. The registry now only providers access to the provider classes, not
the instances.

- ``provider.get_app()`` has been removed -- use ``provider.app`` instead.

- ``SocialApp.objects.get_current()`` has been removed.

- The ``SocialApp`` model now has additional fields ``provider_id``, and
``settings``.

- The OpenID Connect provider ``SOCIALACCOUNT_PROVIDERS`` settings structure
changed. Instead of the OpenID Connect specific ``SERVERS`` construct, it
now uses the regular ``APPS`` approach. Please refer to the OpenID Connect
provider documentation for details.

- The Telegram provider settings structure, it now requires to app. Please
refer to the Telegram provider documentation for details.

- The Facebook provider loaded the Facebook connect ``sdk.js`` regardless of the
value of the ``METHOD`` setting. To prevent tracking, now it only loads the
Javascript if ``METHOD`` is explicitly set to ``"js_sdk"``.