CODEWITHSUNDEEP
google-chromegoogle-chrome-extensionsame-origin-policy
Stan
Stan

Reputation: 8768

Access-Control-Allow-Origin error in a chrome extension

I have a chrome extension which monitors the browser in a special way, sending some data to a web-server. In the current configuration this is the localhost. So the content script contains a code like this:

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(data)...
xhr.open('GET', url, true);
xhr.send();

where url parameter is 'http://localhost/ctrl?params' (or http://127.0.0.1/ctrl?params - it doesn't matter).

Manifest-file contains all necessary permissions for cross-site requests.

The extension works fine on most sites, but on one site I get the error:

XMLHttpRequest cannot load http://localhost/ctrl?params. Origin http://www.thissite.com is not allowed by Access-Control-Allow-Origin.

I've tried several permissions which are proposed here (*://*/*, http://*/*, and <all_urls>), but no one helped to solve the problem.

So, the question is what can be wrong with this specific site (apparently there may be another sites with similar misbehaviour, and I'd like to know the nature of this), and how to fix the error?

Upvotes: 1

Views: 6909

Answers (2)

Mihai Parparita
Mihai Parparita

Reputation: 4236

(tl;dr: see two possible workarounds at the end of the answer)

This is the series of events that happens, which leads to the behavior that you see:

  1. http://www.wix.com/ begins to load
  2. It has a <script> tag that asynchronously loads the Facebook Connect script: 
    (function() {
  var e = document.createElement('script');
  e.type = 'text/javascript';
  e.src = document.location.protocol +
    '//connect.facebook.net/en_US/all.js';
  e.async = true;
  document.getElementById('fb-root').appendChild(e);
}());
  3. Once the HTML (but not resources, including the Facebook Connect script) of the wix.com page loads, the DOMContentLoaded event fires. Since your content script uses "run_at" : "document_end", it gets injected and run at this time.
  4. Your content script runs the following code (as best as I can tell, it wants to do the bulk of its work after the load event fires): 
    window.onload = function() {
  // code that eventually does the cross-origin XMLHttpRequest
};
  5. The Facebook Connect script loads, and it has its own load event handler, which it adds with this snippet: 
    (function() {
  var oldonload=window.onload;
  window.onload=function(){
    // Run new onload code
    if(oldonload) {
      if(typeof oldonload=='string') {
        eval(oldonload);
      } else {
        oldonload();
      }
    }
  };
})();
    (this is the first key part) Since your script set the onload property, oldonload is your script's load handler.
  6. Eventually, all resources are loaded, and the load event handler fires.
  7. Facebook Connect's load handler is run, which run its own code, and then invokes oldonload. (this is the second key part) Since the page is invoking your load handler, it's not running it in your script's isolated world, but in the page's "main world". Only the script's isolated world has cross-origin XMLHttpRequest access, so the request fails.

To see a simplified test case of this, see this page (which mimics http://www.wix.com), which loads this script (which mimics Facebook Connect). I've also put up simplified versions of the content script and extension manifest.

The fact that your load handler ends up running in the "main world" is most likely a manifestation of Chrome bug 87520 (the bug has security implications, so you might not be able to see it).

There are two ways to work around this:

  1. Instead of using "run_at" : "document_end" and a load event handler, you can use the default running time (document_idle, after the document loads) and just have your code run inline.
  2. Instead of adding your load event handler by setting the window.onload property, use window.addEventListener('load', func). That way your event handler will not be visible to the Facebook Connect, so it'll get run in the content script's isolated world.

Upvotes: 10

buley
buley

Reputation: 29208

The access control origin issue you're seeing is likely manifest in the headers for the response (out of your control), rather than the request (under your control).

Access-Control-Allow-Origin is a policy for CORS, set in the header. Using PHP, for example, you use a set of headers like the following to enable CORS:

header('Access-Control-Allow-Origin: http://blah.com');
header('Access-Control-Allow-Credentials: true' );
header('Access-Control-Allow-Headers: Content-Type, Content-Disposition, attachment');

If sounds like that if the server is setting a specific origin in this header, then your Chrome extension is following the directive to allow cross-domain (POST?) requests from only that domain.

Upvotes: 1

Related Questions