JQuery, CORS, JSON (no padding) and authentication issues

Question

I have two domains. I am trying to access a JSON object from one domain through a page to another. I read everything I could find on this issue, and still can not understand it.

The JSON domain has the following settings:

Header set Access-Control-Allow-Origin "*" Header set Access-Control-Allow-Methods "GET, OPTIONS" Header set Access-Control-Allow-Headers "origin, authorization, accept" 

From my other domain, I call the following:

 $.ajax({ type:'get', beforeSend: function(xhr) { var auth = // authentication; xhr.setRequestHeader("Authorization", "Basic " + auth); } url:myUrl, dataType:'json', error: function(xhr, textStatus, errorThrown) { console.log(textStatus, errorThrown); } }) 

I know that "auth" is initialized correctly (registered and verified). However, this does not work. In the Firefox Console, I get the request URL: ...

 Request Method: OPTIONS Status Code: HTTP/1.1 401 Authorization Required 

If I get rid of the beforeSend:... part beforeSend:... , I see the following

 Request Method: GET Status Code: HTTP/1.1 401 Authorization Required 

However, a JSON serving domain can also serve JSONP. I do not want to use this, mainly because the application will constantly work in a dedicated browser, and I am worried about this problem . More importantly, I would really like to know what is really wrong with what I do. I know that for practical purposes there are various ways to overcome JSONP memory leak (for example, without using jQuery).

Anyway, when I used JSONP, my code looked like this:

 $.ajax({ url:newUrl, dataType:'jsonp', jsonp:'jsonp' }).done(function(d){console.log(d)}) 

It turns out the following

 Request Method: GET Status Code: HTTP/1.1 200 OK 

after he prompts me a warning window for the username and password.

Is there a fundamental difference in how jQuery handles JSONP requests, not JSON requests? And if so, how can I fix it?

Thanks.

Edit: this is what I found.

Basically, since I need authentication, the GET request sends an authorization header. However, this is not a "simple" header, so the browser sends a request before the flight (OPTIONS). However, this pre-validation request has no authentication, and therefore the server rejected it. The "solution" was to configure the server so that the OPTIONS request did not require authentication and report it with an HTTP status of 200.

Link: http://www.kinvey.com/blog/item/61-kinvey-adds-cross-origin-resource-sharing-cors

mail-archive [.com] / [e-mail] /msg00790.html(not allowed to post more links)

Unfortunately, the “solution” only works with Firefox, not Chrome. Chrome just shows the request in red, but it does not give me more information about why it failed.

Edit 2: Fixed in Chrome. The server I was trying to get data on had a security certificate that was not trusted. Because of this, a preview request in Chrome. Solution superuser [.com] / questions / 27268 / how-do-i-disable-the-warning-chrome-give-if-a-security-certificate-is-not-trust (no more links allowed)

Answer 1

Welp, now that I have enough time later, I could answer this question and accept it.

When trying to send a GET json request to a server with headers, the browser will first send an OPTION request to make sure that you can access it. Unfortunately, this OPTION request cannot authenticate. This means that if you want to send GET using auth, the server must enable the option without authorization. As soon as I did this, everything began to work.

Answer 2

Some examples available here can further illustrate how access control can be combined with CORS. In particular, an example with a GET certificate. Access control requires that the request set the withCredentials flag to true on XMLHttpRequest , and for the server processing the OPTIONS method, to do two things:

• Set Access-Control-Allow-Credentials: true
• Do not use the * wildcard in the Access-Control-Allow-Origin header. This should be set to the origin exactly in accordance with the MDN docs in HTTP Access Control (CORS).

Essentially, the thing handling the OPTIONS request should send back the appropriate response headers so that you can execute this accounting request.

In your question, you stated that the service you are interacting with returns Access-Control-Allow-Origin: * , which is incompatible with the cross-domain identity request. This is necessary to return the origin specifically.

The aforementioned MDN Http Access Control (CORS) documentation also contains a link to server-side access control documentation that describes how the server can potentially respond to various cross-domain domain requests, including processing a cross-domain POST request that requires you to send back the correct headers in response to the OPTIONS method. You can find this example here .

Answer 3

Why don't you try typing the URL that you extract from JSON from your browser and see what happens. It looks like you literally just need to authenticate with this other website in order to access it.

If your site should work in other browsers, such as IE, you, by the way, will need JSONP. Security will not allow you to work with a cross-site request. The titles of this will not change. I believe that you will also need to add a security policy to your headers.