Django-allauth

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

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

- OIDC: You can now configure whether or not PKCE is enabled per app by
including ``"oauth_pkce_enabled": True`` in the app settings.

- The OpenStreetMap provider is deprecated. You can set it up as an OpenID Connect provider instead.


Fixes
-----

- A ``NoReverseMatch`` could occur when using ``ACCOUNT_LOGIN_BY_CODE_REQUIRED =
True`` while ``ACCOUNT_LOGIN_BY_CODE_ENABLED = False``, fixed.

- The ``PasswordResetDoneView`` did not behave correctly when using Django's
``LoginRequiredMiddleware``, as it was not properly marked as
``login_not_required``.

- When verifying an email address by code, the success URL was hardcoded to the
email management view, instead of calling the
``get_email_verification_redirect_url()`` adapter method.


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

- Headless: ``settings.ACCOUNT_EMAIL_VERIFICATION_BY_CODE_MAX_ATTEMPTS`` was not
enforced, fixed. Note that the related verification endpoint will return a
409 in case the maximum limit is exceeded, as at that point the pending email
verification stage is aborted.

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

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

- OAuth2/OIDC: When setting up multiple apps for the same provider, you can now
configure a different scope per app by including ``"scope": [...]`` in the app
settings.

- Facebook login: Facebook `Limited Login
<https://developers.facebook.com/docs/facebook-login/limited-login>`_ is now
supported via the Headless API. When you have a Limited Login JWT obtained
from the iOS SDK, you can use the Headless "provider token" flow to login with
it.


Fixes
-----

- When using ``HEADLESS_ONLY = True`` together with
``ACCOUNT_REAUTHENTICATION_REQUIRED = True``, you could run into a
``NoReverseMatch`` when connecting a social acount. Fixed.

- In headless mode, submitting a login code when the login flow expired resulted
in a 500. Fixed -- it now returns a 409.

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

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.