1

I'm encountering a bit of a strange issue when making an Ajax cross domain request. I get the following error in the console of chrome dev tools:

No 'Access-Control-Allow-Origin' header is present on the requested resource error

However, when I look at the network requests, it passes the browsers CORS preflight request because request changes from OPTIONS which it was when it was failing preflight request to GET, and the response is as I would get via postman. However, the Ajax failure message is triggered so even though in dev tools the request appears to succeed, I can't access the successful response via the JavaScript.

Additional info is that the file that is making the ajax request is just an HTML file with inline JavaScript that I open directly from the file directory. I'm thinking this might be my problem but couldn't find anything that explicitly says this so I am wanting confirmation.

Note with respect to the API: the appropriate access control headers are set

TripWire
  • 532
  • 7
  • 18
  • "passes the browsers CORS preflight request because status is 200" — The HTTP status and the ability to pass a preflight request (if there is one) are not connected. Only the headers specified in the CORS spec matter for that. – Quentin Mar 29 '17 at 08:19
  • Sorry I set all those headers server side, seems to pass preflight request because it changes from an OPTIONS request to a GET request. Is that more technically correct or still incorrect? – TripWire Mar 29 '17 at 08:28
  • "I set all those headers server side" — the browser says you didn't – Quentin Mar 29 '17 at 08:30
  • How does it make a GET request then? Wouldn't it fail and stop at OPTIONS request like it was before I made the header changes? – TripWire Mar 29 '17 at 08:32
  • I'm confused about the fact the browser says that when I can see the response header has it set, or does it have to be set for both the GET and the OPTIONS request? Currently I only set it for the response of the OPTIONS request – TripWire Mar 29 '17 at 08:34
  • "does it have to be set for both the GET and the OPTIONS request? " — Yes, of course it does. – Quentin Mar 29 '17 at 08:37
  • "Currently I only set it for the response of the OPTIONS request" — That's your problem. – Quentin Mar 29 '17 at 08:37
  • Thank you Quentin! I only just learnt about CORS so I didn't know it needed to validate on every request, I thought that was the purpose of the OPTIONS request. So thank you for your patience. I had read a few of these questions on stack overflow but must have missed he detail of needing to set it for all requests as opposed to just the OPTIONS request. – TripWire Mar 29 '17 at 08:41

1 Answers1

0

You have to pass some (if not all, I haven't checked) with every response, not only the response to the pre-flight OPTIONS request.

Alex Pánek
  • 413
  • 2
  • 8
  • Sorry, could you elaborate on this a bit? I don't really understand. The GET request (which was previously failing on the preflight request) but was then fixed by setting appropriate headers to respond to options request e.g access-control-allow-domain: * is the request which is succeeding and shows expected response in dev tools in terms of data returning but is still hitting the failure method in js – TripWire Mar 29 '17 at 08:23
  • I also added access-control-allow-headers: [HEADERS] and access-control-allow-methods: [METHODS] - not sure if I got pluralisation of those headers right because I'm away from the code right now – TripWire Mar 29 '17 at 08:26
  • Adding the appropriate headers to the `OPTIONS` response is not enough. You'll have to add some/all of the CORS headers to *every* response for the browser to acknowledge it. – Alex Pánek Mar 29 '17 at 08:31
  • Ahhh thank you Alex, will confirm that this works in a couple of hours and then mark your answer as correct! – TripWire Mar 29 '17 at 08:35