Log message:
py-django-allauth: updated to 0.61.1

0.61.1 (2024-02-09)
*******************

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.

Log message:
py-django-allauth: updated to 0.61.0

0.61.0 (2024-02-07)
*******************

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.

Log message:
py-django-allauth: updated to 0.60.1

0.60.1 (2024-01-15)
*******************

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.

0.60.0 (2024-01-05)
*******************

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

- Google One Tap Sign-In is now supported.

- You can now more easily change the URL to redirect to after a successful password
  change/set via the newly introduced ``get_password_change_redirect_url()``
  adapter method.

- You can now configure the primary key of all models by configuring
  ``ALLAUTH_DEFAULT_AUTO_FIELD``, for example to:
  ``"hashid_field.HashidAutoField"``.

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

- You can now specify the URL path prefix that is used for all OpenID Connect
  providers using ``SOCIALACCOUNT_OPENID_CONNECT_URL_PREFIX``. By default, it is
  set to ``"oidc"``, meaning, an OpenID Connect provider with provider ID
  ``foo`` uses ``/accounts/oidc/foo/login/`` as its login URL. Set it to empty
  (``""``) to keep the previous URL structure (``/accounts/foo/login/``).

- The SAML default attribute mapping for ``uid`` has been changed to only
  include ``urn:oasis:names:tc:SAML:attribute:subject-id``. If the SAML response
  does not contain that, it will fallback to use ``NameID``.

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.

Log message:
*: latest py-sphinx only support Python 3.9+

Log message:
py-django-allauth: updated to 0.55.2

0.55.2 (2023-08-30)
*******************

Fixes
-----

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

0.55.1 (2023-08-30)
*******************

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``.

Log message:
py-django-allauth: updated to 0.55.0

0.55.0 (2023-08-22)
*******************

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``.

Log message:
py-django-allauth: add version 0.54.0

Integrated set of Django applications addressing authentication, registration,
account management as well as 3rd party (social) account authentication.