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.

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

0.63.1 (2024-05-17)
*******************

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

- When only ``allauth.account`` was installed, you could run into an exception
  stating "allauth.socialaccount not installed, yet its models are
  imported.". This has been fixed.

- When ``SOCIALACCOUNT_EMAIL_AUTHENTICATION`` was turned on, and a user would
  connect a third-party account for which email authentication would kick in,
  the connect was implicitly skipped. Fixed.

- The recommendation from the documentation to protect the Django admin login
  could cause an infinite redirect loop in case of
  ``AUTHENTICATED_LOGIN_REDIRECTS``. A decorator ``secure_admin_login()`` is now
  offered out of the box to ensure that the Django admin is properly secured by
  allauth (e.g. rate limits, 2FA).

- Subpackages from the ``tests`` package were packaged, fixed.

0.63.0 (2024-05-14)
*******************

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

- New providers: TikTok, Lichess.

- Starting since version 0.62.0, new email addresses are always stored as lower
  case. In this version, we take the final step and also convert existing data
  to lower case, alter the database indices and perform lookups
  accordingly. Migrations are in place.  For rationale, see the note about email
  case sensitivity in the documentation.

- An official API for single-page and mobile application support is now
  available, via the new ``allauth.headless`` app.

- Added support for a honeypot field on the signup form. Real users do not see
  the field and therefore leave it empty. When bots do fill out the field
  account creation is silently skipped.

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

0.62.1 (2024-04-24)
*******************

- The ``tests`` package was accidentally packaged, fixed.

0.62.0 (2024-04-22)
*******************

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

- Added a dummy provider, useful for testing purposes: \ 
``allauth.socialaccount.providers.dummy``.

- Added a new provider, Atlassian

- Next URL handling been streamlined to be consistently applied. Previously, the
  password reset, change and email confirmation views only supported the
  ``success_url`` class-level property.

- Added support for logging in by email using a special code, also known as
  "Magic Code Login"

- Email addresses are now always stored as lower case. For rationale, see the
  note about email case sensitivity in the documentation.

- You can now alter the ``state`` parameter that is typically passed to the
  provider by overriding the new ``generate_state_param()`` adapter method.

- The URLs were not "hackable". For example, while \ 
``/accounts/login/`` is valid
  ``/accounts/`` was not. Similarly, ``/accounts/social/connections/`` was
  valid, but ``/accounts/social/`` resulted in a 404. This has been
  addressed. Now, ``/accounts/`` redirects to the login or email management
  page, depending on whether or not the user is authenticated.  All
  ``/accounts/social/*`` URLs are now below ``/accounts/3rdparty/*``, where
  ``/accounts/social/connections`` is moved to the top-level
  ``/accounts/3rdparty/``.  The old endpoints still work as redirects are in
  place.

- Added a new setting, ``SOCIALACCOUNT_ONLY``, which when set to ``True``,
  disables all functionality with respect to local accounts.

- The OAuth2 handshake was not working properly in case of
  ``SESSION_COOKIE_SAMESITE = "Strict"``, fixed.

- Facebook: the default Graph API version is now v19.0.

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

0.61.1 (2024-02-09)
*******************

Fixes
-----

- Fixed a ``RuntimeWarning`` that could occur when running inside an async
  environment (``'SyncToAsync' was never awaited``).

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

- As part of the Google OAuth handshake, an ID token is obtained by direct
  machine to machine communication between the server running django-allauth and
  Google. Because of this direct communication, we are allowed to skip checking
  the token signature according to the `OpenID Connect Core 1.0 specification
  <https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>`_.
  However, as django-allauth is used and built upon by third parties, this is an
  implementation detail with security implications that is easily overlooked. To
  mitigate potential issues, verifying the signature is now only skipped if it
  was django-allauth that actually fetched the access token.