Django-allauth

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

Fixes
-----

- A regression occurred in the newly introduced support using
``LoginRequiredMiddleware``, fixed.

- For email verification by link, it is not an issue if the user runs into rate
limits. The reason is that the link is session independent. Therefore, if the
user hits rate limits, we can just silently skip sending additional
verification emails, as the previous emails that were already sent still
contain valid links. This is different from email verification by code. Here,
the session contains a specific code, meaning, silently skipping new
verification emails is not an option, and we must block the login instead. The
latter was missing, fixed.

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

Fixes
-----

- When email verification by code was used, adding additional email addresses
over at the email management page fired the ``email_added`` signal prematurely
as the email address instance was still unsaved. Fixed.

- The newly introduced logic to redirect to pending login stages has now been
integrated in the ``RedirectAuthenticatedUserMixin`` so that the existing
behavior of invoking ``get_authenticated_redirect_url()`` when already
authenticated is respected.

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

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

- Added transparent support for Django's ``LoginRequiredMiddleware`` (new since
Django 5.1).

- The ``usersessions`` app now emits signals when either the IP address or user
agent for a session changes.

- Added support for signup using a passkey. See
``settings.MFA_PASSKEY_SIGNUP_ENABLED``.


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

- When the user is partially logged in (e.g. pending 2FA, or login by code),
accessing the login/signup page now redirects to the pending login stage. This
is similar to the redirect that was already in place when the user was fully
authenticated while accessing the login/signup page. As a result, cancelling
(logging out of) the pending stage requires an actual logout POST instead of
merely linking back to e.g. the login page. The builtin templates handle this
change transparently, but if you copied any of the templates involving the
login stages you will have to adjust the cancel link into a logout POST.

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

Fixes
-----

- Verifying the email address by clicking on the link would no longer log you in, even
in case of ``ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION = True``.


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

- It was already the case that you could not enable TOTP 2FA if your account had
unverified email addresses. This is necessary to stop a user from claiming
email addresses and locking other users out. This safety check is now added to
WebAuthn security keys as well.

- In case a user signs in into an account using social account email
authentication (``SOCIALACCOUNT_EMAIL_AUTHENTICATION``) and the email used is
not verified, the password of the account is now wiped (made unusable) to
prevent the person that created the account (without verifying it) from
signing in.

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

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.