Django-allauth

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

- ...

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

- The ``tests`` package was accidentally packaged, fixed.

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

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

- Added a dummy provider, useful for testing purposes: ``allauth.socialaccount.providers.dummy``.

- Added a new provider, Atlassian

- Next URL handling been streamlined to be consistently applied. Previously, the
password reset, change and email confirmation views only supported the
``success_url`` class-level property.

- Added support for logging in by email using a special code, also known as
"Magic Code Login"

- Email addresses are now always stored as lower case. For rationale, see the
note about email case sensitivity in the documentation.

- You can now alter the ``state`` parameter that is typically passed to the
provider by overriding the new ``generate_state_param()`` adapter method.

- The URLs were not "hackable". For example, while ``/accounts/login/`` is valid
``/accounts/`` was not. Similarly, ``/accounts/social/connections/`` was
valid, but ``/accounts/social/`` resulted in a 404. This has been
addressed. Now, ``/accounts/`` redirects to the login or email management
page, depending on whether or not the user is authenticated. All
``/accounts/social/*`` URLs are now below ``/accounts/3rdparty/*``, where
``/accounts/social/connections`` is moved to the top-level
``/accounts/3rdparty/``. The old endpoints still work as redirects are in
place.

- Added a new setting, ``SOCIALACCOUNT_ONLY``, which when set to ``True``,
disables all functionality with respect to local accounts.

- The OAuth2 handshake was not working properly in case of
``SESSION_COOKIE_SAMESITE = "Strict"``, fixed.

- Facebook: the default Graph API version is now v19.0.

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

Fixes
-----

- Fixed a ``RuntimeWarning`` that could occur when running inside an async
environment (``'SyncToAsync' was never awaited``).


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

- As part of the Google OAuth handshake, an ID token is obtained by direct
machine to machine communication between the server running django-allauth and
Google. Because of this direct communication, we are allowed to skip checking
the token signature according to the `OpenID Connect Core 1.0 specification
<https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>`_.
However, as django-allauth is used and built upon by third parties, this is an
implementation detail with security implications that is easily overlooked. To
mitigate potential issues, verifying the signature is now only skipped if it
was django-allauth that actually fetched the access token.

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

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

- Added support for account related security notifications. When
``ACCOUNT_EMAIL_NOTIFICATIONS = True``, email notifications such as "Your
password was changed", including information on user agent / IP address from where the change
originated, will be emailed.

- Google: Starting from 0.52.0, the ``id_token`` is being used for extracting
user information. To accommodate for scenario's where django-allauth is used
in contexts where the ``id_token`` is not posted, the provider now looks up
the required information from the ``/userinfo`` endpoint based on the access
token if the ``id_token`` is absent.


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

- MFA: It was possible to reuse a valid TOTP code within its time window. This
has now been addressed. As a result, a user can now only login once per 30
seconds (``MFA_TOTP_PERIOD``).


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

- The rate limit mechanism has received an update. Previously, when specifying
e.g. ``"5/m"`` it was handled implicitly whether or not that limit was per IP,
per user, or per action specific key. This has now been made explicit:
``"5/m/user"`` vs ``"5/m/ip"`` vs ``"5/m/key"``. Combinations are also supported
now: ``"20/m/ip,5/m/key"`` . Additionally, the rate limit mechanism is now used
throughout, including email confirmation cooldown as well as limitting failed login
attempts. Therefore, the ``ACCOUNT_LOGIN_ATTEMPTS_LIMIT`` and
``ACCOUNT_EMAIL_CONFIRMATION_COOLDOWN`` settings are deprecated.
See :doc:`Rate Limits <../account/rate_limits>` for details.

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

Fixes
-----

- User sessions: after changing your password in case of ``ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE = False``, the list of
sessions woud be empty instead of showing your current session.

- SAML: accessing the SLS/ACS views using a GET request would result in a crash (500).

- SAML: the login view did not obey the ``SOCIALACCOUNT_LOGIN_ON_GET = False`` setting.


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

- Formally, email addresses are case sensitive because the local part (the part
before the "") can be a case sensitive user name. To deal with this,
workarounds have been in place for a long time that store email addresses in
their original case, while performing lookups in a case insensitive
style. This approach led to subtle bugs in upstream code, and also comes at a
performance cost (``__iexact`` lookups). The latter requires case insensitive
index support, which not all databases support. Re-evaluating the approach in
current times has led to the conclusion that the benefits do not outweigh the
costs. Therefore, email addresses are now always stored as lower case, and
migrations are in place to address existing records.