Update django-allauth to 0.54.0
Created by: pyup-bot
This PR updates django-allauth from 0.35.0 to 0.54.0.
Changelog
0.54.0
*******************
Note worthy changes
-------------------
- Dropped support for EOL Python versions (3.5, 3.6).
Security notice
---------------
- Even when account enumeration prevention was turned on, it was possible for an
attacker to infer whether or not a given account exists based upon the
response time of an authentication attempt. Fixed.0.53.1
*******************
Note worthy changes
-------------------
- Example base template was missing ``{% load i18n}``, fixed.0.53.0
*******************
Note worthy changes
-------------------
- You can now override the use of the ``UserTokenForm`` over at the
``PasswordResetFromKeyView`` by configuring ``ACCOUNT_FORMS["user_token"]`` to
allow the change of the password reset token generator.
- The Google API URLs are now configurable via the provider setting which
enables use-cases such as overriding the endpoint during integration tests to
talk to a mocked version of the API.0.52.0
*******************
Note worthy changes
-------------------
- Officially support Django 4.1.
- New providers: OpenID Connect, Twitter (OAuth2), Wahoo, DingTalk.
- Introduced a new provider setting ``OAUTH_PKCE_ENABLED`` that enables the
PKCE-enhanced Authorization Code Flow for OAuth 2.0 providers.
- When ``ACCOUNT_PREVENT_ENUMERATION`` is turned on, enumeration is now also
prevented during signup, provided you are using mandatory email
verification. There is a new email template
(`templates/account/email/acccount_already_exists_message.txt`) that will be
used in this scenario.
- Updated URLs of Google's endpoints to the latest version; removed a redundant
``userinfo`` call.
- Fixed Pinterest provider on new api version.0.51.0
*******************
Note worthy changes
-------------------
- New providers: Snapchat, Hubspot, Pocket, Clever.
Security notice
---------------
The reset password form is protected by rate limits. There is a limit per IP,
and per email. In previous versions, the latter rate limit could be bypassed by
changing the casing of the email address. Note that in that case, the former
rate limit would still kick in.0.50.0
*******************
Note worthy changes
-------------------
- Fixed compatibility issue with setuptools 61.
- New providers: Drip.
- The Facebook API version now defaults to v13.0.0.49.0
*******************
Note worthy changes
-------------------
- New providers: LemonLDAP::NG.
- Fixed ``SignupForm`` setting username and email attributes on the ``User`` class
instead of a dummy user instance.
- Email addresses POST'ed to the email management view (done in order to resend
the confirmation email) were not properly validated. Yet, these email
addresses were still added as secondary email addresses. Given the lack of
proper validation, invalid email addresses could have entered the database.
- New translations: Romanian.
Backwards incompatible changes
------------------------------
- The Microsoft ``tenant`` setting must now be specified using uppercase ``TENANT``.
- Changed naming of ``internal_reset_url_key`` attribute in
``allauth.account.views.PasswordResetFromKeyView`` to ``reset_url_key``.0.48.0
*******************
Note worthy changes
-------------------
- New translations: Catalan, Bulgarian.
- Introduced a new setting ``ACCOUNT_PREVENT_ENUMERATION`` that controls whether
or not information is revealed about whether or not a user account exists.
**Warning**: this is a work in progress, password reset is covered, yet,
signing up is not.
- The ``ACCOUNT_EMAIL_CONFIRMATION_COOLDOWN`` is now also respected when using
HMAC based email confirmations. In earlier versions, users could trigger email
verification mails without any limits.
- Added builtin rate limiting (see ``ACCOUNT_RATE_LIMITS``).
- Added ``internal_reset_url_key`` attribute in
``allauth.account.views.PasswordResetFromKeyView`` which allows specifying
a token parameter displayed as a component of password reset URLs.
- It is now possible to use allauth without having ``sites`` installed. Whether or
not sites is used affects the data models. For example, the social app model
uses a many-to-many pointing to the sites model if the ``sites`` app is
installed. Therefore, enabling or disabling ``sites`` is not something you can
do on the fly.
- The ``facebook`` provider no longer raises ``ImproperlyConfigured``
within ``{% providers_media_js %}`` when it is not configured.
Backwards incompatible changes
------------------------------
- The newly introduced ``ACCOUNT_PREVENT_ENUMERATION`` defaults to ``True`` impacting
the current behavior of the password reset flow.
- The newly introduced rate limiting is by default turned on. You will need to provide
a ``429.html`` template.
- The default of ``SOCIALACCOUNT_STORE_TOKENS`` has been changed to
``False``. Rationale is that storing sensitive information should be opt in, not
opt out. If you were relying on this functionality without having it
explicitly turned on, please add it to your ``settings.py``.0.47.0
*******************
Note worthy changes
-------------------
- New providers: Gumroad.
Backwards incompatible changes
------------------------------
- Added a new setting ``SOCIALACCOUNT_LOGIN_ON_GET`` that controls whether or not
the endpoints for initiating a social login (for example,
"/accounts/google/login/") require a POST request to initiate the
handshake. As requiring a POST is more secure, the default of this new setting
is ``False``.
Security notice
---------------
Automatically signing in users into their account and connecting additional
third party accounts via a simple redirect ("/accounts/facebook/login/") can
lead to unexpected results and become a security issue especially when the
redirect is triggered from a malicious web site. For example, if an attacker
prepares a malicious website that (ab)uses the Facebook password recovery
mechanism to first sign into his/her own Facebook account, followed by a
redirect to connect a new social account, you may end up with the attacker's
Facebook account added to the account of the victim. To mitigate this,
``SOCIALACCOUNT_LOGIN_ON_GET`` is introduced.0.46.0
*******************
Note worthy changes
-------------------
- New providers: Gitea, MediaWiki.
- New translations: Georgian, Mongolian.
- Django 3.2 compatibility.0.45.0
*******************
Note worthy changes
-------------------
- New providers: Feishu, NetIQ, Frontier, CILogin.0.44.0
******
- Better compatibility with Django 3.20.43.0
*******************
Note worthy changes
-------------------
- New translation: Slovenian.
- If ``ACCOUNT_LOGIN_ATTEMPTS_LIMIT`` is set and the user successfully
resets their password, the timeout is cleared to allow immediate login.
- You can now limit the amount of email addresses a user can associate to his
account by setting ``ACCOUNT_MAX_EMAIL_ADDRESSES``.
- New providers: Apple, Okta, Stocktwits, Zoho, Zoom.
- If email verification is set to mandatory, the email address you use to login
with must now be verified as well. In previous versions, it was sufficient if
the account had at least one verified email address, not necessarily the one
used to login with.
- Added a new setting: ``ACCOUNT_SIGNUP_REDIRECT_URL`` -- the URL (or URL
name) to redirect to directly after signing up.
Backwards incompatible changes
------------------------------
- In previous versions, the ``allauth`` app included a ``base.html``
template. This template could conflict with an equally named template at
project level. Therefore, ``base.html`` has now been moved to
``account/base.html`` -- you will need to check your templates and likely
override ``account/base.html`` within your project.0.42.0
*******************
Note worthy changes
-------------------
- New providers: EDX, Yandex, Mixer.
- Fixed Twitch ``get_avatar_url()`` method to use the profile picture retrieved
by new user details endpoint introduced in version 0.40.0.
- The Facebook API version now defaults to v7.0.0.41.0
*******************
Security notice
---------------
- See `CVE-2019-19844
<https://www.djangoproject.com/weblog/2019/dec/18/security-releases/>`_.
Note worthy changes
-------------------
- New providers: Exist.io., YNAB, Amazon Cognito.
- You can now store OAuth credentials directly in your
``settings.SOCIALACCOUNT_PROVIDERS`` settings instead of storing them in the
database using a ``SocialApp`` record.
- Adding Keycloak Provider
Backwards incompatible changes
------------------------------
- Dropped Python 2 and Django 1 compatibility.0.40.0
*******************
Note worthy changes
-------------------
- The ``instagram`` provider now extracts the user's full name.
- New provider: NextCloud (OAuth2)
- Added an ``SDK_URL`` setting for customizing the loading of the Facebook
JavaScript SDK.
- Updated Twitch provider to use new authentication endpoints
(``https://id.twitch.tv``) over deprecated v5 endpoints
(``https://api.twitch.tv/kraken``)
- Added support for Patreon API v2, with API v1 set as default for
backwards compatibility.
Backwards incompatible changes
------------------------------
- ``Twitch``: The new API's profile data is different in both
structure and content than the old V5 endpoint. Any project
that relies on data from ``SocialAccount.extra_data`` should
refer to the new API user endpoint documentation:
https://dev.twitch.tv/docs/api/reference/#get-users0.39.1
*******************
Note worthy changes
-------------------
- The ``linkedin_oauth2`` provider now gracefully deals with old V1
data that might still be present in ``SocialAccount.extra_data``.
Backwards incompatible changes
------------------------------
- The ``globus`` provider's ``extract_uid`` now uses the openid
required field ``sub`` instead of the ``create_time`` field.0.39.0
*******************
Note worthy changes
-------------------
- New providers: JupyterHub (OAuth2), Steam (OpenID)
- Refactor translations: Portuguese (Portugal).
- Add testing for Django 2.2 (no code changes required)
Backwards incompatible changes
------------------------------
- ``linkedin_oauth2``: As the LinkedIn V1 API is deprecated, the user info
endpoint has been moved over to use the API V2. The format of the user
``extra_data`` is different and the profile picture is absent by default.0.38.0
*******************
Security notice
---------------
The ``{% user_display user %}`` tag did not escape properly. Depending on the
username validation rules, this could lead to XSS issues.
Note worthy changes
-------------------
- New provider: Vimeo (OAuth2).
- New translations: Basque.0.37.1
*******************
Backwards incompatible changes
------------------------------
- Dropped the ``x-li-src: msdk`` headers from the ``linkedin_oauth2`` handshake.
This header is only required for mobile tokens, and breaks the regular flow.
Use the ``HEADERS`` setting to add this header if you need it.0.37.0
*******************
Note worthy changes
-------------------
- The Battle.net login backend now recognizes ``apac`` as a valid region.
- User model using a ``UUIDField`` as it's primary key can now be logged
in upon email confirmation (if using ``ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION``).
- New providers: Agave, Cern, Disqus, Globus.
- New translation: Danish.0.36.0
*******************
Note worthy changes
-------------------
- New providers: Telegram, QuickBooks.
- The Facebook API version now defaults to v2.12.
- ORCID upgraded to use API v2.1.
Security notice
---------------
- In previous versions, the authentication backend did not invoke the
``user_can_authenticate()`` method, potentially allowing users with
``is_active=False`` to authenticate when the allauth authentication backend
was used in a non allauth context.