Changelog
### 4.6.0
```
------------------
* Drop Django 3.2 to 4.1 support.
```
### 4.5.0
```
------------------
* Drop Python 3.8 support.
* Support Python 3.13.
```
### 4.4.0
```
------------------
* Support Django 5.1.
```
### 4.3.1
```
------------------
* Fixed ASGI compatibility on Python 3.12.
Thanks to Adrian Capitanu for the report in `Issue 908 <https://github.com/adamchainz/django-cors-headers/issues/908>`__ and Rooyal in `PR #911 <https://github.com/adamchainz/django-cors-headers/pull/911>`__.
```
### 4.3.0
```
------------------
* Avoid adding the ``access-control-allow-credentials`` header to unallowed responses.
Thanks to Adam Romanek in `PR 888 <https://github.com/adamchainz/django-cors-headers/pull/888>`__.
* Support Django 5.0.
```
### 4.2.0
```
------------------
* Drop Python 3.7 support.
```
### 4.1.0
```
------------------
* Support Python 3.12.
```
### 4.0.0
```
------------------
* Add ``CORS_ALLOW_PRIVATE_NETWORK`` setting, which enables support for the Local Network Access draft specification.
Thanks to Issac Kelly in `PR 745 <https://github.com/adamchainz/django-cors-headers/pull/745>`__ and jjurgens0 in `PR #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 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.
```
### 3.14.0
```
-------------------
* 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 793 <https://github.com/adamchainz/django-cors-headers/pull/793>`__.
```
### 3.13.0
```
-------------------
* Support Python 3.11.
* Support Django 4.1.
```
### 3.12.0
```
-------------------
* Drop support for Django 2.2, 3.0, and 3.1.
```
### 3.11.0
```
-------------------
* Drop Python 3.6 support.
```
### 3.10.1
```
-------------------
* Prevent a crash when an invalid ``Origin`` header is sent.
Thanks to minusf for the report in `Issue 701 <https://github.com/adamchainz/django-cors-headers/issues/701>`__.
```
### 3.10.0
```
-------------------
* Support Python 3.10.
```
### 3.9.0
```
------------------
* Support Django 4.0.
```
### 3.8.0
```
------------------
* 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.
```
### 3.7.0
```
------------------
* Support Django 3.2.
```
### 3.6.0
```
------------------
* Drop Python 3.5 support.
* Support Python 3.9.
```
### 3.5.0
```
------------------
* Following Django’s example in
`Ticket 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.
```
### 3.4.0
```
------------------
* Add Django 3.1 support.
```
### 3.3.0
```
------------------
* 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.
```
### 3.2.1
```
------------------
* Update LICENSE file to Unix line endings, fixing issues with license checker
``pip-licenses`` (`Issue
477 <https://github.com/adamchainz/django-cors-headers/issues/477>`__).
```
### 3.2.0
```
------------------
* 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.
```
### 3.1.1
```
------------------
* Support the value `file://` for origins, which is accidentally sent by some
versions of Chrome on Android.
```
### 3.1.0
```
------------------
* 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``.
```
### 3.0.2
```
------------------
* Add a hint to the ``corsheaders.E013`` check to make it more obvious how to
resolve it.
```
### 3.0.1
```
------------------
* Allow 'null' in ``CORS_ORIGIN_WHITELIST`` check.
```
### 3.0.0
```
------------------
* ``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.
```
### 2.5.3
```
------------------
* Tested on Django 2.2. No changes were needed for compatibility.
* Tested on Python 3.7. No changes were needed for compatibility.
```
### 2.5.2
```
------------------
* Improve inclusion of tests in ``sdist`` to ignore ``.pyc`` files.
```
### 2.5.1
```
------------------
* Include test infrastructure in ``sdist`` to allow consumers to use it.
```
### 2.5.0
```
------------------
* Drop Django 1.8, 1.9, and 1.10 support. Only Django 1.11+ is supported now.
```
### 2.4.1
```
------------------
* Fix ``DeprecationWarning`` from importing ``collections.abc.Sequence`` on
Python 3.7.
```
### 2.4.0
```
------------------
* Always add 'Origin' to the 'Vary' header for responses to enabled URL's,
to prevent caching of responses intended for one origin being served for
another.
```
### 2.3.0
```
------------------
* Match ``CORS_URLS_REGEX`` to ``request.path_info`` instead of
``request.path``, so the patterns can work without knowing the site's path
prefix at configuration time.
```
### 2.2.1
```
------------------
* Add ``Content-Length`` header to CORS preflight requests. This fixes issues
with some HTTP proxies and servers, e.g. AWS Elastic Beanstalk.
```
Links
- PyPI: https://pypi.org/project/django-cors-headers
- Changelog: https://data.safetycli.com/changelogs/django-cors-headers/
This PR updates django-cors-headers from 2.2.0 to 4.6.0.
Changelog
### 4.6.0 ``` ------------------ * Drop Django 3.2 to 4.1 support. ``` ### 4.5.0 ``` ------------------ * Drop Python 3.8 support. * Support Python 3.13. ``` ### 4.4.0 ``` ------------------ * Support Django 5.1. ``` ### 4.3.1 ``` ------------------ * Fixed ASGI compatibility on Python 3.12. Thanks to Adrian Capitanu for the report in `Issue 908 <https://github.com/adamchainz/django-cors-headers/issues/908>`__ and Rooyal in `PR #911 <https://github.com/adamchainz/django-cors-headers/pull/911>`__. ``` ### 4.3.0 ``` ------------------ * Avoid adding the ``access-control-allow-credentials`` header to unallowed responses. Thanks to Adam Romanek in `PR 888 <https://github.com/adamchainz/django-cors-headers/pull/888>`__. * Support Django 5.0. ``` ### 4.2.0 ``` ------------------ * Drop Python 3.7 support. ``` ### 4.1.0 ``` ------------------ * Support Python 3.12. ``` ### 4.0.0 ``` ------------------ * Add ``CORS_ALLOW_PRIVATE_NETWORK`` setting, which enables support for the Local Network Access draft specification. Thanks to Issac Kelly in `PR 745 <https://github.com/adamchainz/django-cors-headers/pull/745>`__ and jjurgens0 in `PR #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 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. ``` ### 3.14.0 ``` ------------------- * 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 793 <https://github.com/adamchainz/django-cors-headers/pull/793>`__. ``` ### 3.13.0 ``` ------------------- * Support Python 3.11. * Support Django 4.1. ``` ### 3.12.0 ``` ------------------- * Drop support for Django 2.2, 3.0, and 3.1. ``` ### 3.11.0 ``` ------------------- * Drop Python 3.6 support. ``` ### 3.10.1 ``` ------------------- * Prevent a crash when an invalid ``Origin`` header is sent. Thanks to minusf for the report in `Issue 701 <https://github.com/adamchainz/django-cors-headers/issues/701>`__. ``` ### 3.10.0 ``` ------------------- * Support Python 3.10. ``` ### 3.9.0 ``` ------------------ * Support Django 4.0. ``` ### 3.8.0 ``` ------------------ * 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. ``` ### 3.7.0 ``` ------------------ * Support Django 3.2. ``` ### 3.6.0 ``` ------------------ * Drop Python 3.5 support. * Support Python 3.9. ``` ### 3.5.0 ``` ------------------ * Following Django’s example in `Ticket 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. ``` ### 3.4.0 ``` ------------------ * Add Django 3.1 support. ``` ### 3.3.0 ``` ------------------ * 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. ``` ### 3.2.1 ``` ------------------ * Update LICENSE file to Unix line endings, fixing issues with license checker ``pip-licenses`` (`Issue 477 <https://github.com/adamchainz/django-cors-headers/issues/477>`__). ``` ### 3.2.0 ``` ------------------ * 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. ``` ### 3.1.1 ``` ------------------ * Support the value `file://` for origins, which is accidentally sent by some versions of Chrome on Android. ``` ### 3.1.0 ``` ------------------ * 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``. ``` ### 3.0.2 ``` ------------------ * Add a hint to the ``corsheaders.E013`` check to make it more obvious how to resolve it. ``` ### 3.0.1 ``` ------------------ * Allow 'null' in ``CORS_ORIGIN_WHITELIST`` check. ``` ### 3.0.0 ``` ------------------ * ``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. ``` ### 2.5.3 ``` ------------------ * Tested on Django 2.2. No changes were needed for compatibility. * Tested on Python 3.7. No changes were needed for compatibility. ``` ### 2.5.2 ``` ------------------ * Improve inclusion of tests in ``sdist`` to ignore ``.pyc`` files. ``` ### 2.5.1 ``` ------------------ * Include test infrastructure in ``sdist`` to allow consumers to use it. ``` ### 2.5.0 ``` ------------------ * Drop Django 1.8, 1.9, and 1.10 support. Only Django 1.11+ is supported now. ``` ### 2.4.1 ``` ------------------ * Fix ``DeprecationWarning`` from importing ``collections.abc.Sequence`` on Python 3.7. ``` ### 2.4.0 ``` ------------------ * Always add 'Origin' to the 'Vary' header for responses to enabled URL's, to prevent caching of responses intended for one origin being served for another. ``` ### 2.3.0 ``` ------------------ * Match ``CORS_URLS_REGEX`` to ``request.path_info`` instead of ``request.path``, so the patterns can work without knowing the site's path prefix at configuration time. ``` ### 2.2.1 ``` ------------------ * Add ``Content-Length`` header to CORS preflight requests. This fixes issues with some HTTP proxies and servers, e.g. AWS Elastic Beanstalk. ```Links
- PyPI: https://pypi.org/project/django-cors-headers - Changelog: https://data.safetycli.com/changelogs/django-cors-headers/