1

I'm making an ajax call to a different domain. My team member added the Access-Control-Allow-Origin header to http://localhost:3000 .

$.ajax({
          type: 'GET',
          url: myurl,
          beforeSend: function(xhr) {
              xhr.setRequestHeader('Authorization', 'Bearer '+authorization);
          },
          crossDomain: true,
          // xhrFields: {
          //   withCredentials: true
          // },
          contentType: 'application/json',
          dataType: 'JSON',
          success: function (response) {
            if(time_one === 0){
              main_result = response;
              time_one++;
            }
            if(response.length==0){
              alert("NO Data; Try a valid search")
              $('.row3, #paging').hide();
              $('.loading-gif').show();
              $('#table').html('');
              myCallBack(main_result);
            }
            else{
              $('#table').html('')
              myCallBack(response);
            }
          },
          error: function(err) {
            $('.loading-gif').hide();
            $(".pageblocker").hide();
            alert('Error: '+JSON.stringify(err));
            myCallBack(main_result)
          }
      });

If I try this way, I'm getting 'Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.' I don't understand why I'm getting such type of error even after adding the ACAO header.

And I also noticed another error if I add the 'withCredentials' attribute. 'Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'http://localhost:3000' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.' I don't understand the difference between those two errors.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Sai Velamuri
  • 15
  • 1
  • 9

1 Answers1

1

The server at myurl must return the Access-Control-Allow-Origin response header.

If you don’t have access to the server environment for the myurl server to configure that server to send the Access-Control-Allow-Origin response header, then you’ll need to make the request through proxy instead. You can find more details on setting up that kind of proxy in the answer at "No 'Access-Control-Allow-Origin' header is present on the requested resource".

Anyway the fact that adding Access-Control-Allow-Origin to the http://localhost:3000 backend has no effect in this case is expected—because Access-Control-Allow-Origin is a response header that must be sent by the server a request is made to. http://localhost:3000 isn’t that—instead it’s the server serving the frontend JavaScript code that’s initiating the request.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS is the best resource for getting an understanding of how all this stuff works. Some other answers here to take a look at:

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • Hmm, a little confusing but I'll get through it. What was the other error mean, when I was adding 'withCredentials' attribute? In the mdn dev ntk it says exposing the header. I'm thinking that exposing header means header is visible to all including the auth token. – Sai Velamuri Jun 03 '17 at 05:09
  • “exposing a header” means whether *the browser* will expose a response header to your frontend JavaScript code. The server sends a full set of headers in the response regardless, and the browser gets the full response including all the headers the server has sent. But the browser won’t expose some headers to your frontend JavaScript code unless the server has included in the response an Access-Control-Expose-Headers response header that includes the particular header names that your frontend JavaScript code wants access to – sideshowbarker Jun 03 '17 at 05:15
  • Thank you for the response! To be honest, this was way over my head. Could you suggest me where to look at the basics of this so that I can understand your answer? – Sai Velamuri Jun 03 '17 at 05:19
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS is the best resource for getting an understanding of how all this stuff works. And see my updated answer for links to some other answers here you might want to take a look at, including https://stackoverflow.com/questions/44196915/angular-2-http-post-returns-data-but-goes-to-error-cors/44198143#44198143 and https://stackoverflow.com/questions/44034905/why-isnt-rack-cors-filtering-incoming-requests-according-to-rspec/44035843#44035843 – sideshowbarker Jun 03 '17 at 05:34
  • Hi, Sorry for the late response. I think what you meant started to make sense. "Anyway the fact that adding ACAO to the http://localhost:3000 backend has no effect in this case is expected—because ACAO is a response header that must be sent by the server a request is made to. http://localhost:3000 isn’t that—instead it’s the server serving the frontend JavaScript code that’s initiating the request." You said the server is serving the frontend javascript. This javascript will make request. So, adding this server address to ACAO will do the trick, right! – Sai Velamuri Jun 15 '17 at 19:27
  • Right, configuring the server at `myurl` to include an `Access-Control-Allow-Origin: http://localhost:3000` response header in its response will do the trick – sideshowbarker Jun 15 '17 at 20:18