openstack/swift
Code Issues Proposed changes

Add more doc and test for cors_expose_headers option

Browse Source 
In follow-up to the related change, mention the new
cors_expose_headers option (and other proxy-server.conf
options) in the CORS doc.

Add a test for the cors options being loaded into the
proxy server.

Improve CORS comments in docs.

Change-Id: I647d8f9e9cbd98de05443638628414b1e87d1a76
Related-Change: I5ca90a052f27c98a514a96ee2299bfa1b6d46334
This commit is contained in:
Alistair Coles
2017-03-13 17:12:13 +00:00
committed by Tim Burke
parent 956172623c
commit 904e7c97f1
5 changed files with 73 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/manpages/proxy-server.conf.5
View File

@@ -142,11 +142,14 @@ This optional suffix (default is empty) that would be appended to the swift tran
id allows one to easily figure out from which cluster that X-Trans-Id belongs to.
This is very useful when one is managing more than one swift cluster.
.IP \fBcors_allow_origin\fR
Use a comma separated list of full URL (http://foo.bar:1234,https://foo.bar)
List of origin hosts that are allowed for CORS requests in addition to what
the container has set. Use a comma separated list of full URL (http://foo.bar:1234,https://foo.bar)
.IP \fBstrict_cors_mode\fR
The default is true.
If True (default) then CORS requests are only allowed if their Origin header
matches an allowed origin. Otherwise, any Origin is allowed.
.IP \fBcors_expose_headers\fR
Comma separated list of headers to expose through Access-Control-Expose-Headers
Comma separated list of headers to expose through Access-Control-Expose-Headers,
in addition to the defaults and any headers set in container metadata.
.IP \fBnice_priority\fR
Modify scheduling priority of server processes. Niceness values range from -20
(most favorable to the process) to 19 (least favorable to the process).

7
doc/source/cors.rst
View File

@@ -28,6 +28,11 @@ The supported headers are,
| | Space separated. |
+------------------------------------------------+------------------------------+
In addition the the values set in container metadata, some cluster-wide values
may also be configured using the ``strict_cors_mode``, ``cors_allow_origin``
and ``cors_expose_headers`` in ``proxy-server.conf``. See
``proxy-server.conf-sample`` for more information.
Before a browser issues an actual request it may issue a `preflight request`_.
The preflight request is an OPTIONS call to verify the Origin is allowed to
make the request. The sequence of events are,
@@ -48,6 +53,8 @@ returns the following values for this header,
* all metadata headers (``X-Container-Meta-*`` for containers and
``X-Object-Meta-*`` for objects)
* headers listed in ``X-Container-Meta-Access-Control-Expose-Headers``
* headers configured using the ``cors_expose_headers`` option in
``proxy-server.conf``
.. note::
An OPTIONS request to a symlink object will respond with the options for

14
doc/source/deployment_guide.rst
View File

@@ -1765,14 +1765,14 @@ cert_file Path to the ssl
key_file Path to the ssl .key. This
should be enabled for testing
purposes only.
cors_allow_origin This is a list of hosts that
are included with any CORS
request by default and
returned with the
Access-Control-Allow-Origin
header in addition to what
cors_allow_origin List of origin hosts that are allowed
for CORS requests in addition to what
the container has set.
strict_cors_mode True
strict_cors_mode True If True (default) then CORS
requests are only allowed if their
Origin header matches an allowed
origin. Otherwise, any Origin is
allowed.
cors_expose_headers This is a list of headers that
are included in the header
Access-Control-Expose-Headers