W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

preflighted CORS requests and redirects: principally impossible?

From: Nico Schlömer <nico.schloemer@gmail.com>
Date: Fri, 22 Jan 2016 15:34:16 +0000
Message-ID: <CAK6Z60fnXZq0v0=Nq-LSOe7k5YSVSQPcNfy9gnbqxpzv-057_Q@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: André Gaul <andre@paperhive.org>
Hi everyone,

I'm designing an API that allows the user to authenticate (using tokens)
and that contains redirects within the same domain. Now, for an
unauthenticated request to an endpoint that returns 303,

GET /documents/123 --> 303 redirect to `/documents/abc`
GET /documents/abc --> 200

everything works nicely.

Let's do an authenticated request to the same endpoint where the
`Authorization` header is sent. This makes the request preflighted and the
browser does a preliminary `OPTIONS request, i.e.

OPTIONS /documents/123 --> 204 (everything okay, please proceed)
GET /documents/123? --> 303 redirect to `/documents/abc`

At this point, instead of `GET`ting the actual resource at
`/documents/abc`, the browser yields

XMLHttpRequest cannot load http://localhost:8000/people/username/nschloe.
The request was redirected to 'http://localhost:8000/people/YDHa-B2FhMie',
which is disallowed for cross-origin requests that require preflight.

This behavior is in accordance with the standard [1]:

> 7.1.5 Cross-Origin Request with Preflight
> If the response has an HTTP status code that is not in the 2xx range
> Apply the network error steps.

This seems to mean that one cannot do redirects for authenticated resources
-- even if the redirect is on the same domain (localhost). Can this really
be true or am I missing something?

(The use case here are resources that require authentication and that are
available from several end points, one of which will serve the content
(200), the others redirect to it (303).)

Nico Schlömer

[1] https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
Received on Friday, 22 January 2016 15:34:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC