Changelog
### 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.
```
Links
- PyPI: https://pypi.org/project/django-allauth
- Changelog: https://data.safetycli.com/changelogs/django-allauth/
- Homepage: https://allauth.org
This PR updates django-allauth[mfa] from 0.63.2 to 0.63.3.
Changelog
### 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. ```Links
- PyPI: https://pypi.org/project/django-allauth - Changelog: https://data.safetycli.com/changelogs/django-allauth/ - Homepage: https://allauth.org