search

ModelChimp / modelchimp

Experiment tracking for machine and deep learning projects
https://www.modelchimp.com/
BSD 2-Clause "Simplified" License
126 stars 12 forks source link

Update django-allauth to 0.55.0 #1202

Closed pyup-bot closed 1 year ago

pyup-bot commented 1 year ago

This PR updates django-allauth from 0.39.1 to 0.55.0.

Changelog ### 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"``. ``` ### 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.2 ``` ### 0.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-users ```
Links - PyPI: https://pypi.org/project/django-allauth - Changelog: https://pyup.io/changelogs/django-allauth/ - Homepage: https://www.intenct.nl/projects/django-allauth/
pyup-bot commented 1 year ago

Closing this in favor of #1206