Update django-allauth to 0.63.5

[pyup-bot]

This PR updates django-allauth from 0.54.0 to 0.63.5.

Changelog

0.63.4

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

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

- The ``__str__()`` method of the ``SocialToken`` model returned the access
token. As a consequence, logging or printing tokens otherwise would expose the
access token. Now, the method no longer returns the token. If you want to
log/print tokens, you will now have to explicitly log the ``token`` field of
the ``SocialToken`` instance.

- Enumeration prevention: the behavior on the outside of an actual signup versus
a signup where the user already existed was not fully identical, fixed.

0.63.3

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

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

- In ``HEADLESS_ONLY`` mode, the ``/accounts/<provider>/login/`` URLs were still
available, fixed.

- The few remaining OAuth 1.0 providers were not compatible with headless mode,
fixed.

- Depending on where you placed the ``secure_admin_login(admin.site.login)``
protection you could run into circular import errors, fixed.


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

- SAML: IdP initiated SSO is disabled by default, see security notice below.


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

- SAML: ``RelayState`` was used to keep track of whether or not the login flow
was IdP or SP initiated. As ``RelayState`` is a separate field, not part of
the ``SAMLResponse`` payload, it is not signed and thereby making the SAML
login flow vulnerable to CSRF/replay attacks. Now, ``InResponseTo`` is used
instead, addressing the issue for SP initiated SSO flows. IdP initiated SSO
remains inherently insecure, by design. For that reason, it is now disabled by
default. If you need to support IdP initiated SSO, you will need to opt-in to
that by adding ``"reject_idp_initiated_sso": False`` to your advanced SAML
provider settings.

0.63.2

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

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

- ``allauth.headless`` now supports the ``is_open_for_signup()`` adapter method.
In case signup is closed, a 403 is returned during signup.

- Connecting a third-party account in ``HEADLESS_ONLY`` mode failed if the
connections view could not be reversed, fixed.

- In case a headless attempt was made to connect a third-party account that was already
connected to a different account, no error was communicated to the frontend. Fixed.

- When the headless provider signup endpoint was called while that flow was not pending,
a crash would occur. This has been fixed to return a 409 (conflict).

- Microsoft provider: the URLs pointing to the login and graph API are now
configurable via the app settings.

0.63.1

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

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

- When only ``allauth.account`` was installed, you could run into an exception
stating "allauth.socialaccount not installed, yet its models are
imported.". This has been fixed.

- When ``SOCIALACCOUNT_EMAIL_AUTHENTICATION`` was turned on, and a user would
connect a third-party account for which email authentication would kick in,
the connect was implicitly skipped. Fixed.

- The recommendation from the documentation to protect the Django admin login
could cause an infinite redirect loop in case of
``AUTHENTICATED_LOGIN_REDIRECTS``. A decorator ``secure_admin_login()`` is now
offered out of the box to ensure that the Django admin is properly secured by
allauth (e.g. rate limits, 2FA).

- Subpackages from the ``tests`` package were packaged, fixed.

0.63.0

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

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

- New providers: TikTok, Lichess.

- Starting since version 0.62.0, new email addresses are always stored as lower
case. In this version, we take the final step and also convert existing data
to lower case, alter the database indices and perform lookups
accordingly. Migrations are in place.  For rationale, see the note about email
case sensitivity in the documentation.

- An official API for single-page and mobile application support is now
available, via the new ``allauth.headless`` app.

- Added support for a honeypot field on the signup form. Real users do not see
the field and therefore leave it empty. When bots do fill out the field
account creation is silently skipped.

0.62.1

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

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

0.62.0

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

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.


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

- The django-allauth required dependencies are now more fine grained.  If you do
not use any of the social account functionality, a ``pip install
django-allauth`` will, e.g., no longer pull in dependencies for handling
JWT. If you are using social account functionality, install using ``pip install
"django-allauth[socialaccount]"``.  That will install the dependencies covering
most common providers. If you are using the Steam provider, install using ``pip
install django-allauth[socialaccount,steam]``.

0.61.1

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

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.

0.61.0

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

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.

0.60.1

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

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.

0.60.0

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

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

0.59.0

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

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

- The MFA authenticator model now features "created at" an "last used "at"
timestamps.

- The MFA authenticator model is now registered with the Django admin.

- Added MFA signals emitted when authenticators are added, removed or (in case
of recovery codes) reset.

- There is now an MFA adapter method ``can_delete_authenticator(authenticator)``
available that can be used to prevent users from deactivating e.g. their TOTP
authenticator.

- Added a new app, user sessions, allowing users to view a list of all their
active sessions, as well as offering a means to end these sessions.

- A configurable timeout (``SOCIALACCOUNT_REQUESTS_TIMEOUT``) is now applied to
all upstream requests.

- Added a setting ``ACCOUNT_EMAIL_UNKNOWN_ACCOUNTS`` to disable sending of
emails to unknown accounts.

- You can now override the MFA forms via the ``MFA_FORMS`` setting.


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

- The account adapter method ``should_send_confirmation_mail()`` signature
changed. It now takes an extra ``signup`` (boolean) parameter.

- Removed OAuth 1.0 based Bitbucket provider and LinkedIn provider.

0.58.2

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

Fixes
-----

- Added rate limiting to the MFA login form.

0.58.1

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

Fixes
-----

- Fixed missing ``{% load allauth %}`` in the login cancelled and verified email
required template.

0.58.0

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

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

- The ``SocialAccount.extra_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

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

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.

0.56.1

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

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.

0.56.0

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

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",
                 },
             }
         ]
     }
 }

0.55.2

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

Fixes
-----

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

0.55.1

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

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

0.55.0

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

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

Links

• PyPI: https://pypi.org/project/django-allauth
• Changelog: https://data.safetycli.com/changelogs/django-allauth/
• Homepage: https://allauth.org

[pyup-bot]

Closing this in favor of #107