Log message:
py-django-allauth: updated to 65.4.1

65.4.1 (2025-02-07)

Fixes

- To make way for a future ``"phone"`` method, \ 
``AUTHENTICATION_METHOD`` was
  removed in favor of a new ``LOGIN_METHODS``. While this change was done in a
  backwards compatible manner within allauth scope, other packages accessing
  ``allauth.account.app_settings.AUTHENTICATION_METHOD`` would break. Fixed.

Log message:
py-django-allauth: updated to 65.4.0

65.4.0 (2025-02-06)

Note worthy changes

- The setting ``ACCOUNT_AUTHENTICATION_METHOD: str`` (with values
  ``"username"``, ``"username_email"``, \ 
``"email"``) has been replaced by
  ``ACCOUNT_LOGIN_METHODS: set[str]``. which is a set of values including
  ``"username"`` or ``"email"``. This change is performed in \ 
a backwards
  compatible manner.

- Headless: when ``HEADLESS_SERVE_SPECIFICATION`` is set to ``True``, the API
  specification will be served dynamically, over at
  ``/_allauth/openapi.(yaml|json|html)``.  The
  ``HEADLESS_SPECIFICATION_TEMPLATE_NAME`` can be configured to choose between
  Redoc (``"headless/spec/redoc_cdn.html"``) and Swagger (
  (``"headless/spec/swagger_cdn.html"``).

- Headless: added a new setting, ``HEADLESS_CLIENTS`` which you can use to limit
  the types of API clients (app/browser).

- Headless: expanded the React SPA example to showcase integration with
  Django Ninja as well as Django REST framework.

- Headless: added out of the box support for being able to use the headless
  session tokens with Django Ninja and Django REST framework.

Log message:
py-django-allauth: updated to 65.3.1

65.3.1 (2025-12-25)
*******************

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 (2024-11-30)
*******************

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 (2024-11-08)
*******************

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.

Log message:
py-*: remove unused tool dependency

py-setuptools includes the py-wheel functionality nowadays

Log message:
*: clean-up after python38 removal

Log message:
py-django-allauth: updated to 0.63.6

0.63.6 (2024-07-12)
*******************

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

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

0.63.5 (2024-07-11)
*******************

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.

0.63.4 (2024-07-10)
*******************

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.

Log message:
py-django-allauth: updated to 0.63.3

0.63.3 (2024-05-31)
*******************

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.

Log message:
py-django-allauth: updated to 0.63.2

0.63.2 (2024-05-24)
*******************

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

- ``allauth.headless`` now supports the ``is_open_for_signup()`` adapter method.
  In case signup is closed, a 403 is returned during signup.

- Connecting a third-party account in ``HEADLESS_ONLY`` mode failed if the
  connections view could not be reversed, fixed.

- In case a headless attempt was made to connect a third-party account that was \ 
already
  connected to a different account, no error was communicated to the frontend. Fixed.

- When the headless provider signup endpoint was called while that flow was not \ 
pending,
  a crash would occur. This has been fixed to return a 409 (conflict).

- Microsoft provider: the URLs pointing to the login and graph API are now
  configurable via the app settings.