Django-allauth

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

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

- Verifying email addresses by means of a code (instead of a link) is now supported.
See ``settings.ACCOUNT_EMAIL_VERIFICATION_BY_CODE_ENABLED``.

- Added support for requiring logging in by code, so that every user logging in
is required to input a login confirmation code sent by email. See
``settings.ACCOUNT_LOGIN_BY_CODE_REQUIRED``.


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

- In case an ID token is used for authentication, the JTI is now respected to
prevent the possibility of replays instead of solely relying on the expiration
time.

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

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

- Headless: When trying to login while a user is already logged in, you now get
a 409.

- Limited the maximum allowed time for a login to go through the various login
stages. This limits, for example, the time span that the 2FA stage remains
available. See ``settings.ACCOUNT_LOGIN_TIMEOUT``.


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

- Headless: When a user was not fully logged in, for example, because (s)he was
in the process of completing the 2FA process, calling logout would not wipe
the session containing the partially logged in user.

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

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

- The 0.x.y version numbers really did not do justice to the state of the
project, and we are way past the point where a version 1.0 would be
applicable. Additionally, 64 is a nice round number. Therefore, the version
numbering is changed from 0.x.y to x.y.z. We will use a loose form of semantic
versioning. However, please be aware that feature releases may occasionally
include minor documented backwards incompatibilities. Always read the release
notes before upgrading.

- Added support for WebAuthn based security keys and passkey login. Note that
this is currently disabled by default.

- Headless: The TOTP URI is now available in the MFA activation response.

- Headless: When trying to sign up while a user is already logged in, you now get
a 409.

- Headless: You can now alter the user data payload by overriding the newly
introduced ``serialize_user()`` adapter method.

- Headless: The token strategy now allows for exposing refresh tokens and any
other information you may need (such as e.g. ``expires_in``).

- Ensured that email address, given name and family name fields are stored in
the SocialAccount instance. This information was not previously saved in
Amazon Cognito, Edmodo, and MediaWiki SocialAccount instances.

- When multiple third-party accounts of the same provider were connected, the
third-party account connections overview did not always provide a clear
recognizable distinction between those accounts. Now, the
``SocialAccount.__str__()`` has been altered to return the unique username or
email address, rather than a non-unique display name.


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

- Dropped support for Django 3.2, 4.0 and 4.1 (which all reached end of life).
As Django 3.2 was the last to support Python 3.7, support for Python 3.7 is
now dropped as well.

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

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

- When the Facebook provider was configured to use the ``js_sdk`` method the
login page could become vulnerable to an XSS attack.

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

Fixes
-----

- The security fix in 0.63.4 that altered the ``__str__()`` of ``SocialToken``
caused issues within the Amazon Cognito, Atlassian, JupyterHub, LemonLDAP,
Nextcloud and OpenID Connect providers. Fixed.

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

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.