David Goetz 2abb829a5d Make cors work better.

CORS doesn't really work with swift right now. OPTIONS calls for the most part
work but for so called "simple cross-site requests" (i.e. those that don't
require a pre-flight OPTIONS request) Swift always returns the Origin it was
given as the Access-Control-Allow-Origin in the response. This makes CORS
"work" for these requests but if you actually wanted the javascript user agent
to restrict anything for you it wouldn't be able to!

You can duplicate the issue with updated CORS test page:

http://docs.openstack.org/developer/swift/cors.html#test-cors-page

And a public container with an 'X-Container-Meta-Access-Control-Allow-Origin'
that does NOT match the webserver hosting the test-cors-page.

e.g.

with a public container that accepts cross-site requests from "example.com":

`swift post cors-container -m access-control-allow-origin:example.com -r .r:*`

You could point your browser at a copy of the test-cors-page on your
filesystem (the browser will will send 'Origin: null')

Without a token the XMLHttpRequest will not request any custom headers (i.e.
Access-Control-Request-Headers: x-auth-token) and the request will be made
with-out a preflight OPTIONS request (which Swift would have denied anyway
because the origin's don't match)

i.e. fill in "http://saio:8080/v1/AUTH_test/cors-container" for "URL" and
leave "Token" blank.

You would expect that the browser would not complete the request because
"Origin: null" does not match the configured "Access-Control-Allow-Origin:
example.com" on the container metadata, and indeed with this patch - it won't!

Also:

The way cors is set up does not play well with certain applications for swift.
If you are running a CDN on top of swift and you have the
Access-Control-Allow-Origin cors header set to * then you probably want the *
to be cached on the the CDN, not the Origin that happened to result in an
origin request.

Also:

If you were unfortunate enough to allow cors headers to be saved directly
onto objects then this allows them to supersede the headers coming from the
container.

NOTE: There is a change is behavior with this patch. Because its cors, a
      spec that was created only to cause annoyance to all, I'll write out
      what's being changed and hopefully someone will speak up if it breaks
      there stuff.

previous behavior: When a request was made with a Origin header set the
                   cors_validation decorator would always add that origin as
                   the Access-Control-Allow-Origin header in the response-
                   whether the passed origin was a match with the container's
                   X-Container-Meta-Access-Control-Allow-Origin or not, or even
                   if the container did not have CORS set up at all.
new behavior: If strict_cors_mode is set to True in the proxy-server.conf
              (which is the default) the cors_validation decorator will only
              add the Access-Control-Allow-Origin header to the response when
              the request's Origin matches the value set in
              X-Container-Meta-Access-Control-Allow-Origin. NOTE- if the
              container does not have CORS set up it won't just magically start
              working. Furthremore, if the Origin doesn't match the
              Access-Control-Allow-Origin - a successfully authorized request
              (either by token or public ACL) won't be *denied* - it just
              won't include the Access-Control-Allow-Origin header (it's up
              to the security model in the browser to cancel the request
              if the response doesn't include a matching Allow-Origin
              header).  On the other hand, if you want to restrict requests
              with CORS, you can actually do it now.

              If you are worried about breaking current functionality you
              must set:

              strict_cors_mode = False

              in the proxy-server.conf. This will continue with returning the
              passed in Origin as the Access-Control-Allow-Origin in the
              response.

previous: If you had X-Container-Meta-Access-Control-Allow-Origin set to *
          and you passed in Origin: http://hey.com you'd get
          Access-Control-Allow-Origin: http://hey.com back. This was true for
          both OPTIONS and regular reqs.
new: With X-Container-Meta-Access-Control-Allow-Origin set to * you get * back
     for both OPTIONS and regular reqs.

previous: cors headers saved directly onto objects (by allowing them to be
          saved via the allowed_headers config in the object-server conf)
          would be overridden by whatever container cors you have set up.
new: For regular (non-OPTIONS) calls the object headers will be kept. The
     container cors will only be applied to objects without the
     'Access-Control-Allow-Origin' and 'Access-Control-Expose-Headers' headers.
     This behavior doesn't make a whole lot of sense for OPTIONS calls so I
     left that as is. I don't think that allowing cors headers to be saved
     directly onto objects is a good idea and it should be discouraged.

DocImpact

Change-Id: I9b0219407e77c77a9bb1133cbcb179a4c681c4a8

2014-03-11 18:41:46 -07:00

5.9 KiB

Raw Blame History

CORS

CORS is a mechanisim to allow code running in a browser (Javascript for example) make requests to a domain other then the one from where it originated.

Swift supports CORS requests to containers and objects.

CORS metadata is held on the container only. The values given apply to the container itself and all objects within it.

The supported headers are,

Metadata	Use
X-Container-Meta-Access-Control-Allow-Origin	Origins to be allowed to make Cross Origin Requests, space separated.
X-Container-Meta-Access-Control-Max-Age	Max age for the Origin to hold the preflight results.
X-Container-Meta-Access-Control-Expose-Headers	Headers exposed to the user agent (e.g. browser) in the the actual request response. Space separated.

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,

Browser makes OPTIONS request to Swift
Swift returns 200/401 to browser based on allowed origins
If 200, browser makes the "actual request" to Swift, i.e. PUT, POST, DELETE, HEAD, GET

When a browser receives a response to an actual request it only exposes those headers listed in the Access-Control-Expose-Headers header. By default Swift returns the following values for this header,

"simple response headers" as listed on http://www.w3.org/TR/cors/#simple-response-header
the headers etag, x-timestamp, x-trans-id
all metadata headers (X-Container-Meta-* for containers and X-Object-Meta-* for objects)
headers listed in X-Container-Meta-Access-Control-Expose-Headers

Sample Javascript

To see some CORS Javascript in action download the test CORS page (source below). Host it on a webserver and take note of the protocol and hostname (origin) you'll be using to request the page, e.g. http://localhost.

Locate a container you'd like to query. Needless to say the Swift cluster hosting this container should have CORS support. Append the origin of the test page to the container's X-Container-Meta-Access-Control-Allow-Origin header,:

curl -X POST -H 'X-Auth-Token: xxx' \
  -H 'X-Container-Meta-Access-Control-Allow-Origin: http://localhost' \
  http://192.168.56.3:8080/v1/AUTH_test/cont1

At this point the container is now accessible to CORS clients hosted on http://localhost. Open the test CORS page in your browser.

Populate the Token field
Populate the URL field with the URL of either a container or object
Select the request method
Hit Submit

Assuming the request succeeds you should see the response header and body. If something went wrong the response status will be 0.

Test CORS Page

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Test CORS</title>
  </head>
  <body>

    Token<br><input id="token" type="text" size="64"><br><br>

    Method<br>
    <select id="method">
        <option value="GET">GET</option>
        <option value="HEAD">HEAD</option>
        <option value="POST">POST</option>
        <option value="DELETE">DELETE</option>
        <option value="PUT">PUT</option>
    </select><br><br>

    URL (Container or Object)<br><input id="url" size="64" type="text"><br><br>

    <input id="submit" type="button" value="Submit" onclick="submit(); return false;">

    <pre id="response_headers"></pre>
    <p>
    <hr>
    <pre id="response_body"></pre>

    <script type="text/javascript">
      function submit() {
          var token = document.getElementById('token').value;
          var method = document.getElementById('method').value;
          var url = document.getElementById('url').value;

          document.getElementById('response_headers').textContent = null;
          document.getElementById('response_body').textContent = null;

          var request = new XMLHttpRequest();

          request.onreadystatechange = function (oEvent) {
              if (request.readyState == 4) {
                  responseHeaders = 'Status: ' + request.status;
                  responseHeaders = responseHeaders + '\nStatus Text: ' + request.statusText;
                  responseHeaders = responseHeaders + '\n\n' + request.getAllResponseHeaders();
                  document.getElementById('response_headers').textContent = responseHeaders;
                  document.getElementById('response_body').textContent = request.responseText;
              }
          }

          request.open(method, url);
          if (token != '') {
              // custom headers always trigger a pre-flight request
              request.setRequestHeader('X-Auth-Token', token);
          }
          request.send(null);
      }
    </script>

  </body>
</html>

5.9 KiB Raw Blame History

CORS

Sample Javascript

Test CORS Page

5.9 KiB

Raw Blame History