Configuring response to CORS OPTIONS request

We’ve built an endpoint that will be connected to via browser, and Chrome currently denies the connection with the following error: "“Access to XMLHttpRequest at “Endpoint URL” from origin “URL” has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”

So basically, Chrome sends a pre-flight request before the actual web-request, and I’m not finding anywhere in the Appfarm Service tool to configure the response we provide for this pre-flight request. Is it possible to configure at all?

Here you can see a discussion on the topic, where the top response describes what I want to achieve.
In short I need to automatically respond with one extra header: “Access-Control-Allow-Origin: *” and I think we’ll be fine.

We currently do not have a way to respond to these preflight calls. However, it is possible to structure the calls in a way that they do not trigger this preflight. You must adhere to the conditions for a ‘simple request’ as described here: Cross-Origin Resource Sharing (CORS) - HTTP | MDN

This means you cannot send JSON if you want to stay within the definition. But services understand form-data and will automatically parse it into JSON. Creating requests with form-data is relatively straightforward on the frontend

That being said, we’ll register a challenge on this feature / configurability, allowing for service endpoints to be a target for web requests initiating from the browser.

Thank you we’ll try setting up a simple request!

Is it possible to receive a web service request without the bearer token in a header, if it is instead listed in the request body?


You may just add that same bearer token in the url instead, as a “token” URL parameter. For example, you may to a web request towards https://<yoursolution>/api/services/<yourservice>/<yourendpoint>?token=dsdsd....3dfdf

1 Like