Pin django-cors-headers to latest version 2.5.3

[pyup-bot]

This PR pins django-cors-headers to the latest release 2.5.3.

Changelog

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.

2.2.0

------------------

* Django 2.0 compatibility. Again there were no changes to the actual library
code, so previous versions probably work.
* Ensured that ``request._cors_enabled`` is always a ``bool()`` - previously it
could be set to a regex match object.

2.1.0

------------------

* Django 1.11 compatibility. There were no changes to the actual library code,
so previous versions probably work, though they weren't properly tested on
1.11.

2.0.2

------------------

* Fix when the check for ``CORS_MODEL`` is done to allow it to properly add
the headers and respond to ``OPTIONS`` requests.

2.0.1

------------------

* Add support for specifying 'null' in ``CORS_ORIGIN_WHITELIST``.

2.0.0

------------------

* Remove previously undocumented ``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.
* Make sure that ``Access-Control-Allow-Credentials`` is in the response if the
client asks for it.

1.3.1

------------------

* Fix a bug with the single check if CORS enabled added in 1.3.0: on Django
< 1.10 shortcut responses could be generated by middleware above
``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.

1.3.0

------------------

* Add checks to validate the types of the settings.
* Add the 'Do Not Track' header ``'DNT'`` to the default for
``CORS_ALLOW_HEADERS``.
* Add 'Origin' to the 'Vary' header of outgoing requests when not allowing all
origins, as per the CORS spec. Note this changes the way HTTP caching works
with your CORS-enabled responses.
* Check whether CORS should be enabled on a request only once. This has had a
minor change on the conditions where any custom signals will be called -
signals will now always be called *before* ``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.

1.2.2

------------------

* Add ``CorsModel.__str__`` for human-readable text
* Add a signal that allows you to add code for more intricate control over when
CORS headers are added.

1.2.1

------------------

* Made settings dynamically respond to changes, and which allows you to import
the defaults for headers and methods in order to extend them.

1.2.0

------------------

* Drop Python 2.6 support.
* Drop Django 1.3-1.7 support, as they are no longer supported.
* Confirmed Django 1.9 support (no changes outside of tests were necessary).
* Added Django 1.10 support.
* Package as a universal wheel.

1.1.0

------------------

* django-cors-header now supports Django 1.8 with its new application loading
system! Thanks jpadilla for making this possible and sorry for the delay in
making a release.

1.0.0

------------------

django-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.

* Switching this middleware versioning over to semantic versioning
* 46 add user-agent and accept-encoding default headers
* 45 pep-8 this big boy up

0.13

-----------------

* Add support for Python 3
* Updated tests
* Improved docuemntation
* Small bugfixes

0.12

-----------------

* Added an option to selectively enable CORS only for specific URLs

0.11

* Added the ability to specify a regex for whitelisting many origin hostnames
at once

0.10

-----------------

* Introduced port distinction for origin checking
* Use ``urlparse`` for Python 3 support
* Added testcases to project

0.06

-----------------

* Add support for exposed response headers

0.05

-----------------

* Fixed middleware to ensure correct response for CORS preflight requests

0.04

-----------------

* Add ``Access-Control-Allow-Credentials`` control to simple requests

0.03

-----------------

* Bugfix to repair mismatched default variable names

0.02

-----------------

* Refactor/pull defaults into separate file

0.01

-----------------

* Initial release

Links

• PyPI: https://pypi.org/project/django-cors-headers
• Changelog: https://pyup.io/changelogs/django-cors-headers/
• Repo: https://github.com/ottoyiu/django-cors-headers