Hi Marcus:

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

From:

 https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#sending_a_request_with_credentials_included

    CORS-preflight requests must never include credentials. The
    response to a preflight request must specify
    Access-Control-Allow-Credentials: true to indicate that the actual
    request can be made with credentials.

So for now I think allowing anonymous to have "Rest Access"
permissions and establishing a new "CORS Access" permission that
permits OPTIONS with CORS headers is the way to go.

However this opens a can of worms if CORS is applied to all three
services:

  1 rest
  2 xmlrpc
  3 html

Do we need "CORS-rest Access", "CORS-xmlrpc Access" .... permissions
to go along with the "Rest Access", "Web Access", "XMLRPC Access"?

Also should "Rest Access" imply "CORS-Rest Access" so we don't have to
add multiple permissions to a role.

At the moment, I am leaning toward just a "CORS Access" that will work
for any service (rest, xmlrpc, html). It is checked only if the user
doesn't have access to the service (e.g via "Rest Access", "Web
Access"). (This is similar to how roundup already handles search. It
checks for view access to the searched class/property and if not found
looks for search access permissions to the class/property.)

While it is possible to probe for endpoints using a CORS request, I
don't think this a major problem. At the moment the http endpoint
treats an OPTIONS request like a GET request and returns an html page.
The XMLRPC endpoint just hangs waiting for a document/body which will
never come since there is no body/payload in options requests.

Thoughts?