Update dependency django-cors-headers to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
django-cors-headers (changelog)	==2.5.3 -> ==4.7.0

---

Release Notes

adamchainz/django-cors-headers (django-cors-headers)

v4.7.0

Compare Source

• Support Django 5.2.

v4.6.0

Compare Source

• Drop Django 3.2 to 4.1 support.

v4.5.0

Compare Source

• Drop Python 3.8 support.

• Support Python 3.13.

v4.4.0

Compare Source

• Support Django 5.1.

v4.3.1

Compare Source

• Fixed ASGI compatibility on Python 3.12.

  Thanks to Adrian Capitanu for the report in Issue #&#8203;908 <https://github.com/adamchainz/django-cors-headers/issues/908>__ and Rooyal in PR #&#8203;911 <https://github.com/adamchainz/django-cors-headers/pull/911>__.

v4.3.0

Compare Source

• Avoid adding the access-control-allow-credentials header to unallowed responses.

  Thanks to Adam Romanek in PR #&#8203;888 <https://github.com/adamchainz/django-cors-headers/pull/888>__.

• Support Django 5.0.

v4.2.0

Compare Source

• Drop Python 3.7 support.

v4.1.0

Compare Source

• Support Python 3.12.

v4.0.0

Compare Source

• Add CORS_ALLOW_PRIVATE_NETWORK setting, which enables support for the Local Network Access draft specification.

  Thanks to Issac Kelly in PR #&#8203;745 <https://github.com/adamchainz/django-cors-headers/pull/745>__ and jjurgens0 in PR #&#8203;833 <https://github.com/adamchainz/django-cors-headers/pull/833>__.

• Remove three headers from the default "accept list": accept-encoding, dnt, and origin.
  These are Forbidden header names <https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name>__, which means requests JavaScript can never set them.
  Consequently, allowing them via CORS has no effect.

  Thanks to jub0bs for the report in Issue #&#8203;842 <https://github.com/adamchainz/django-cors-headers/issues/842>__.

• Drop the CORS_REPLACE_HTTPS_REFERER setting and CorsPostCsrfMiddleware.
  Since Django 1.9, the CSRF_TRUSTED_ORIGINS setting has been the preferred solution to making CSRF checks pass for CORS requests.
  The removed setting and middleware only existed as a workaround for Django versions before 1.9.

• Add async support to the middleware, reducing overhead on async views.

v3.14.0

Compare Source

• Support Django 4.2.

• Switch from urlparse() to urlsplit() for URL parsing, reducing the middleware runtime up to 5%.
  This changes the type passed to origin_found_in_white_lists(), so if you have subclassed the middleware to override this method, you should check it is compatible (it most likely is).

  Thanks to Thibaut Decombe in PR #&#8203;793 <https://github.com/adamchainz/django-cors-headers/pull/793>__.

v3.13.0

Compare Source

• Support Python 3.11.

• Support Django 4.1.

v3.12.0

Compare Source

• Drop support for Django 2.2, 3.0, and 3.1.

v3.11.0

Compare Source

• Drop Python 3.6 support.

v3.10.1

Compare Source

• Prevent a crash when an invalid Origin header is sent.

  Thanks to minusf for the report in Issue #&#8203;701 <https://github.com/adamchainz/django-cors-headers/issues/701>__.

v3.10.0

Compare Source

• Support Python 3.10.

v3.9.0

Compare Source

• Support Django 4.0.

v3.8.0

Compare Source

• Add type hints.

• Stop distributing tests to reduce package size. Tests are not intended to be
  run outside of the tox setup in the repository. Repackagers can use GitHub's
  tarballs per tag.

v3.7.0

Compare Source

• Support Django 3.2.

v3.6.0

Compare Source

• Drop Python 3.5 support.
• Support Python 3.9.

v3.5.0

Compare Source

• Following Django’s example in
  Ticket #&#8203;31670 <https://code.djangoproject.com/ticket/31670>__ for replacing
  the term “whitelist”, plus an aim to make the setting names more
  comprehensible, the following settings have been renamed:

  • CORS_ORIGIN_WHITELIST -> CORS_ALLOWED_ORIGINS
  • CORS_ORIGIN_REGEX_WHITELIST -> CORS_ALLOWED_ORIGIN_REGEXES
  • CORS_ORIGIN_ALLOW_ALL -> CORS_ALLOW_ALL_ORIGINS

  The old names will continue to work as aliases, with the new ones taking
  precedence.

v3.4.0

Compare Source

• Drop Django 2.0 and 2.1 support.

v3.3.0

Compare Source

• Drop Django 1.11 support. Only Django 2.0+ is supported now.
• Drop the providing_args argument from Signal to prevent a deprecation
  warning on Django 3.1.

v3.2.1

Compare Source

• Update LICENSE file to Unix line endings, fixing issues with license checker
  pip-licenses (Issue #&#8203;477 <https://github.com/adamchainz/django-cors-headers/issues/477>__).

v3.2.0

Compare Source

• Converted setuptools metadata to configuration file. This meant removing the
  __version__ attribute from the package. If you want to inspect the
  installed version, use
  importlib.metadata.version("django-cors-headers")
  (docs <https://docs.python.org/3.8/library/importlib.metadata.html#distribution-versions>__ /
  backport <https://pypi.org/project/importlib-metadata/>__).
• Support Python 3.8.

v3.1.1

Compare Source

• Support the value file:// for origins, which is accidentally sent by some
  versions of Chrome on Android.

v3.1.0

Compare Source

• Drop Python 2 support, only Python 3.5-3.7 is supported now.
• Fix all links for move from github.com/ottoyiu/django-cors-headers to
  github.com/adamchainz/django-cors-headers.

v3.0.2

Compare Source

• Add a hint to the corsheaders.E013 check to make it more obvious how to
  resolve it.

v3.0.1

Compare Source

• Allow 'null' in CORS_ORIGIN_WHITELIST check.

v3.0.0

Compare Source

• CORS_ORIGIN_WHITELIST now requires URI schemes, and optionally ports.
  This is part of the CORS specification
  (Section 3.2 <https://tools.ietf.org/html/rfc6454#section-3.2>_) that was
  not implemented in this library, except from with the
  CORS_ORIGIN_REGEX_WHITELIST setting. It fixes a security issue where the
  CORS middleware would allow requests between schemes, for example from
  insecure http:// Origins to a secure https:// site.

  You will need to update your whitelist to include schemes, for example from
  this:

  .. code-block:: python

  CORS_ORIGIN_WHITELIST = ["example.com"]
  

  ...to this:

  .. code-block:: python

  CORS_ORIGIN_WHITELIST = ["https://example.com"]
  

• Removed the CORS_MODEL setting, and associated class. It seems very few,
  or no users were using it, since there were no bug reports since its move to
  abstract in version 2.0.0 (2017-01-07). If you are using this
  functionality, you can continue by changing your model to not inherit from
  the abstract one, and add a signal handler for check_request_enabled that
  reads from your model. Note you'll need to handle the move to include schemes
  for Origins.

---

Configuration

📅 Schedule: Branch creation - "every weekend" in timezone US/Eastern, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.