Update django-allauth to 0.39.1
Created by: pyup-bot
This PR updates django-allauth from 0.35.0 to 0.39.1.
Changelog
0.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``.
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.