Feature: Access-control-allow-origin: * headers on all responses

Hi,

I am wanting to submit to the API through an AJAX request. However, to do this cors-mode must be enabled (see here for reference https://stackoverflow.com/questions/45591594/fetch-does-not-send-headers).

So could we have the API send Access-control-allow-origin: * headers on responses?

 

Thanks for the work so far guys, this is going to be really useful.

Hi,

  Some of the newer APIs that we are working on already do this. eg. The BIC API will return this in response to a preflight OPTIONS request

Access-Control-Allow-Origin: https://xxx
Access-Control-Allow-Headers: apikey, accept, content-type, origin
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: GET

In this case we reflect the value of the Origin header back to the client in the Access-Control-Allow-Origin rather than using a '*'

Which API are you using, and is your browser performing an OPTIONS like this request prior to the actual GET/POST to get the CORS headers?

 

 

Submitted by rhardy on Thu, 19/04/2018 - 13:15

Hi I am doing an /invoice POST request.

Yes an OPTIONS pre-flight is being done and that is where the request for me returns 401.

OPTIONS https://provider.api-compliance.acc.co.nz/api/v1/claims/vendors/invoice 401 (Unauthorized).

Thanks,

Submitted by sean.stanley on Thu, 19/04/2018 - 14:34

I have made a compliance change so that a preflight OPTIONS request will now work, eg. with curl

curl --cert xxx --key xxx -vk -XOPTIONS -H 'Origin: https://myapp.org' https://provider.api-compliance.acc.co.nz/api/v1/claims/vendors

HTTP/1.1 200 OK
Date: Thu, 19 Apr 2018 03:04:07 GMT
Content-Type: text/plain
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://myapp.org
Access-Control-Allow-Headers: apikey, accept, content-type, origin
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: GET, POST

No apikey is needed since a browser will never send this in a preflight.

ACC architecture will need to approve this in production, since you are calling the API directly from a client and therefore the apikey could be compromised. I assume you have a way to stop the client user from ever seeing your key.

 

Submitted by rhardy on Thu, 19/04/2018 - 15:09

Thanks for the change.

Submitting is going through now. Just working through validation stuff. Currently getting a 500 error though. But I suspect this might be specific to my data rather than a problem with the API.

I might send through my error data and request body for someone to have a look at and maybe they can point out the problem?

Thanks for your assistance.

Submitted by sean.stanley on Thu, 19/04/2018 - 16:31