Hi John,

> A followup. It looks like preflight requests will never send 
> credentials regardless of the credential settings 8-(.
[...]
> Thoughts?

cors-preflight is a different story than the actual cors thing.

i am not really sure if we have common sense here, therefore let me
briefly sum it up:

1) when you issue request to a different url from where the page
actually was loaded in javascript (== CORS), then

2) the browser automatically sends a cors-preflight request right before
your actual request to query the server what he is allowed to do.

this request has no auth info as it's just there to query the server how
to continue, if cors actually is allowed, what headers are allowed, is
sending credentials allowed or not, etc.

3) the answer includes allowed headers, if sending credentials is
allowed, what methods are allowed, etc.

it is therefore an anonymous, public and general information.

this is covered by the first part of the patch.

of course we could limit access to certain "Origin"'s to limit who
acutally is allowed to do cors at all.

4) with this information the browser then crafts the actual cors request
and sends it to the server (including auth cookies - if allowed, uses
only allowed headers, etc).

5) the answer then again needs to have a couple of headers set to inform
the browser that it is still allowed to continue (that covers the second
part of the patch)

therefore you actually have two requests in this case.

so, the question is, where to put the logic and what actually gets sent
in 3)?

letting this all come down through the permission system to the actual
OPTIONS method you mentioned in an earlier post, maybe is not that
useful (and a bit of an overkill) as you basically would have the
same answer for almost any endpoint.

except the allowed methods for that endpoint.

but i think that e.g. when 3) returns that PATCH is allowed and the
browser then issue a PATCH on an item where PATCH actually is *not*
allowed, the browser gets back the error anyway ...

i think we can live with this as it would make things easier.

so for me it would be enough to have a config option "ALLOW_CORS" which
enables/disables the answer to the preflight request (first part of the
patch - 3) form above)

optionally maybe also configurable / default:

   Access-Control-Max-Age / 86400
   Access-Control-Allow-Methods / OPTIONS, GET, POST, PUT, DELETE, PATCH
   Access-Control-Allow-Credentials / true

and maybe some sort of configuring what Origins are allowed.

"*" meaning that the requests Origin header just gets copied (as in the
patch) and some kind of check if it's not "*", maybe regex on the Origin
header ?

the second part of the patch needs to be applied anyway as the browser
dont accept Access-Control-Allow-Credentials: true without
Access-Control-Allow-Origin being set to the Origin of the request (as
you already found out).

And you actually need credentials when you want to do something user
specific with the rest api (as in my case).

... just my thoughts ...

regards,
marcus.