Update django-allauth to 65.3.1

[pyup-bot]

User description

This PR updates django-allauth from 64.2.1 to 65.3.1.

Changelog

65.3.1

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

Fixes
-----

- Headless: When using email verification by code, you could incorrectly
encounter a 409 when attempting to add a new email address while logged in.

- Headless: In contrast to the headed version, it was possible to remove the
last 3rd party account from a user that has no usable password. Fixed.

- Headless: The setting ``ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION`` was not respected,
and always assumed to be ``True``.

65.3.0

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

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

- Added support for TOTP code tolerance (see ``MFA_TOTP_TOLERANCE``).


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

- Authentication by email/password was vulnerable to account enumeration by
means of a timing attack. Thanks to Julie Rymer for the report and the patch.

65.2.0

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

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.

65.1.0

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

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.

65.0.2

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

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.

65.0.1

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

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.

65.0.0

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

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.

Links

• PyPI: https://pypi.org/project/django-allauth
• Changelog: https://data.safetycli.com/changelogs/django-allauth/
• Homepage: https://allauth.org

---

Description

• Upgraded django-allauth to version 65.3.1 to incorporate bug fixes and enhancements.
• This update addresses several issues related to email verification and account management.

---

Changes walkthrough 📝

	Relevant files
Dependencies	requirements.txt Update django-allauth to version 65.3.1                                    requirements.txt Updated django-allauth version from 64.2.1 to 65.3.1. +1/-1

---

💡 Penify usage:
Comment /help on the PR to get a list of all available Penify tools and their descriptions

[penify-dev]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	1, because this is a straightforward version update with no complex changes.
🧪 Relevant tests	No
⚡ Possible issues	No
🔒 Security concerns	No

[penify-dev]

PR Code Suggestions ✨

Category	Suggestion	Score
Testing	Execute tests to confirm that the application remains stable after the update Consider running tests after updating to ensure that the new version does not introduce any regressions. requirements.txt [2] -django-allauth==65.3.1 +# Run tests to confirm stability after update Suggestion importance[1-10]: 8 Why: Running tests after updating dependencies is a critical step to ensure stability, making this suggestion particularly valuable for maintaining application integrity.	8
Compatibility	Verify compatibility of the updated package version with the existing framework version Consider verifying compatibility of django-allauth==65.3.1 with the current Django version to avoid potential issues. requirements.txt [2] -django-allauth==65.3.1 +# Ensure compatibility with Django version Suggestion importance[1-10]: 7 Why: This suggestion addresses a valid concern about compatibility, which is important when updating dependencies, but it does not directly impact the code itself.	7
	Verify that other dependencies remain compatible with the updated package version Ensure that all other dependencies are compatible with django-allauth==65.3.1 to prevent conflicts. requirements.txt [2] -django-allauth==65.3.1 +# Check compatibility with other dependencies Suggestion importance[1-10]: 6 Why: While ensuring compatibility with other dependencies is important, this suggestion is more of a general best practice rather than a specific issue with the current PR.	6
Documentation	Review the release notes for the updated package version to identify any breaking changes Check the release notes for django-allauth==65.3.1 to understand any breaking changes or new features that may affect your application. requirements.txt [2] -django-allauth==65.3.1 +# Review release notes for breaking changes Suggestion importance[1-10]: 7 Why: Understanding breaking changes is crucial when updating dependencies, making this suggestion relevant, though it does not change the code directly.	7