Hello, I have a Mendix REST API which accepts POST requests from a non-Mendix client. Since invalid requests are possible, part of my PRS microflow creates and returns an HTTPResponse object with a ‘403 Forbidden’ error. To deal with a CORS error (MissingAllowOriginHeader) I’ve been getting on the client-side, I added ‘Access-Control-Allow-Origin’ and ‘Access-Control-Allow-Credentials’ headers (shown below). From my observations on the client as well as using cURL, these headers aren’t included in the response when the StatusCode is 403 and the ReasonPhrase is Forbidden. However, when I change the above HTTPResponse creation activity to 200 OK, my custom headers are there and the client’s CORS error goes away. Why the differing behavior? If there is some rule against including access-control headers when responding with a 400-level code, it certainly is an unspoken one since I could find nothing on the subject, inside and outside the Mendix domain. I would appreciate any help. EDIT: From this answer on SO, I’ve discovered this is nginx behavior, which is the cloud app’s server (but not the local one). It seems changing this behavior would require changing the server’s config file, which I believe is inaccessible to a cloud user. Does anyone know of a workaround?
asked
Tyler Dean
2 answers
0
I think the idea is this:
With CORS headers, you can instruct the brower whether to load the resource based on which website the user is on.
When a webserver responds with status 403, that means that it is not returning the resource. It’s returning an error about authentication. So the information of whether to load the reasource or not is not relevant.