CHANGELOG.rst
Tighten some system checks for settings to catch when a string has been provided instead of a sequence of strings, such as for CORS_ALLOW_METHODS = "GET".
Thanks to Baptiste Darthenay in PR #1025 <https://github.com/adamchainz/django-cors-headers/pull/1025>__.
Drop Python 3.9 support.
Drop Python 3.8 support.
Support Python 3.13.
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>__.
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.
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.
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>__.
Support Python 3.11.
Support Django 4.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>__.
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.
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_ORIGINSCORS_ORIGIN_REGEX_WHITELIST -> CORS_ALLOWED_ORIGIN_REGEXESCORS_ORIGIN_ALLOW_ALL -> CORS_ALLOW_ALL_ORIGINSThe old names will continue to work as aliases, with the new ones taking precedence.
providing_args argument from Signal to prevent a deprecation
warning on Django 3.1.pip-licenses (Issue #477 <https://github.com/adamchainz/django-cors-headers/issues/477>__).__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/>__).file:// for origins, which is accidentally sent by some
versions of Chrome on Android.github.com/ottoyiu/django-cors-headers to
github.com/adamchainz/django-cors-headers.corsheaders.E013 check to make it more obvious how to
resolve it.CORS_ORIGIN_WHITELIST check.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.
sdist to ignore .pyc files.sdist to allow consumers to use it.DeprecationWarning from importing collections.abc.Sequence on
Python 3.7.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.Content-Length header to CORS preflight requests. This fixes issues
with some HTTP proxies and servers, e.g. AWS Elastic Beanstalk.request._cors_enabled is always a bool() - previously it
could be set to a regex match object.CORS_MODEL is done to allow it to properly add
the headers and respond to OPTIONS requests.CORS_ORIGIN_WHITELIST.CorsModel as it was causing migration
issues. For backwards compatibility, any users previously using CorsModel
should create a model in their own app that inherits from the new
AbstractCorsModel, and to keep using the same data, set the model's
db_table to 'corsheaders_corsmodel'. Users not using CorsModel
will find they have an unused table that they can drop.Access-Control-Allow-Credentials is in the response if the
client asks for it.CorsMiddleware, before it processed the request, failing with an
AttributeError for request._cors_enabled. Also clarified the docs
that CorsMiddleware should be kept as high as possible in your middleware
stack, above any middleware that can generate such responses.'DNT' to the default for
CORS_ALLOW_HEADERS.HTTP_REFERER gets replaced,
whereas before they could be called before and after. Also this attaches the
attribute _cors_enabled to request - please take care that other
code you're running does not remove it.CorsModel.__str__ for human-readable textdjango-cors-headers is all grown-up :) Since it's been used in production for many many deployments, I think it's time we mark this as a stable release.
0.11 (2013-09-24)
urlparse for Python 3 supportAccess-Control-Allow-Credentials control to simple requests