I'm developing a Greasemonkey script that implements a couple of tools onto a webpage. This script makes a request for data from
http://localhost/chess/heartbeat.php
Now currently in Firefox I am getting this console error which totally stops my jQuery AJAX request for data.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
http://localhost/chess/heartbeat.php.
This can be fixed by moving the resource to the same domain or enabling CORS.
I am able to work around this using Google Chrome. When I have it as a simple browser extension for chrome, I'm able to have it do the same thing as Greasemonkey and I can add the following permissions to the manifest file for the plugin which allows me to make the same data request which Firefox blocked:
"permissions": [
"<all_urls>"
]
Anyway, this works on chrome, but I want to achieve the same effect on Firefox. I've been researching this issue and I can't find a simple answer.
Normally XMLHttpRquest, and that includes jQuery's higher-level API around it, does not allow unrestricted cross-site requests but is limited by the same-origin policy and CORS.
As #epascarello already pointed out, you may use GM.xmlHttpRequest which allows you to perform any cross-site XHR even when the server does not implement CORS or allows the origin site. It also comes with some other goodies.
You should add a #grant GM.xmlHttpRequest metadata block to your user script or your script may break in the future.
Since you mentioned Chrome extensions: Firefox extensions can perform cross-site XHR as well. e.g. most user scripts should be easily portable to an SDK add-on using PageMod and enabling certain permissions analog to what you'd do in a Chrome extension.
Related
I would like to ignore X-frame header on my website so that iframe can load external websites. There are chrome extension like
this one which works perfectly. How can I implement same concept through javascript?
You can’t use frontend JavaScript code running in a browser to cause the X-Frame-Options response header to be ignored. X-Frame-Options is a security feature designed in part as a defense against clickjacking attacks. If any site could just use some JavaScript code to cause browsers to ignore X-Frame-Options, that would pretty much make it completely useless.
That’s the reason why the only way you can cause it to be ignored in your own browser is by intentionally opting-in to insecure browsing by installing an extension as mentioned in the question.
But you can’t use JavaScript to force insecure browsing on other users by bypassing security features like X-Frame-Options that browsers have built-in support for.
I have an addon for Firefox which modifies a page at http://target.com with data from http://data.com. It does this by making an XMLHttpRequest() in the addon javascript and modifying the webpage accordingly. Neither the target nor the source servers are under my control.
This all worked fine until the target.com website changed to using https. As I was loading data from an http: address I got the following error:
Blocked loading mixed active content
Fortunately data.com also supports https, so I changed the data lookup address to https://data.com, and then I got
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://data.com
I read here that I could add the following to my package.json
"permissions": {
"cross-domain-content": ["https://data.com"]
}
And now I don't get any errors, but the Developer Tools Network page doesn't show any connections being made.
Have I hit a dead end? I understand that CORS requires server support but I assumed that as it worked prior to the target server moving to https it would still work now.
Cheers
Rich
That is one of the issues with using libraries (and not Firefox API)
Try using the native Firefox API eg: Connecting to Remote Content
Native Firefox API runs in the browser scope so there is no CORS to consider.
I'm familiar with the Same Origin policy, but what I'm wondering is if firefox actually blocks Ajax POST requests from local files. I've been doing some automated javascript testing, and I've enabled CORS on my server, but I actually don't even see the xhr request making it to firebug, which leads me to believe that firefox is completely blocking it.
When I run the same requests in chrome and allow cross domain requests, it works well.
All modern browsers do that : they consider all requests using the file:// protocol as being cross domain.
The setup is as follows:
Firefox (both 3.x and 4b) with properly set up and working certificates, including a client certificate.
Web page with an XMLHttpRequest() type of AJAX call to a different subdomain.
Custom web server in said subdomain accepting requests, reponding with a permissive Access-Control-Allow-Origin header and requiring client verification.
The problem is that Firefox aborts the request (well, that's what it says in firebug anyway) abruptly. Running the setup with openssl s_server instead hints that Firefox actually doesn't even send the client certificate:
140727260153512:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer
did not return a certificate:s3_srvr.c:2965:ACCEPT
The same exact setup works perfectly with Chrome, suggesting perhaps a bug in Firefox. However, performing the ajax call with a <script> element injected into the DOM seems to work as intended...
So, has anyone else run into this? Is it a bug? Any workarounds? Is there something obvious missing?
Chiming in 5 years later probably isn't much help to the OP, but in case someone else has this issue in the future...
Firefox appears to not send the client certificate with a cross-origin XHR request by default. Setting withCredentials=true on the XHR instance resolved the issue for me. Note that I also did not see this problem with Chrome--only Firefox.
For more info see this Mozilla Dev Network blog post. In particular, the following statement:
By default, in cross-site XMLHttpRequest invocations, browsers will
not send credentials. A specific flag has to be set on the XMLHttpRequest object when it is invoked.
The reason injecting the script works as opposed to a simple XHR request is because of the Single Origin Policy. This would probably explain why Chrome allows the XHR but not FF; Chrome considers the subdomain part of the same origin, but FF does not.
Injecting scripts from other domains (which is what Google Analytics does) is allowed and one of the practices to handle this situation.
The way my team handles this situation is by making a request through a server-side proxy.
I would recommend using a server-side proxy if you can, but the script injection method works fine as long as the code is coming from a trusted source.
I also found this article which describes your situation.
I'm wondering, in IE & Firefox you're able to setup the browser, to allow
cross-domain calls.
I can't find any option in chrome for that (actually, there are in general not too much options at all...)
are there any about:config like things?
Kind Regards
--Andy
This answer was correct when written, but is longer correct, the switch has been deprecated
Chrome has a command line switch for this:
chrome.exe --disable-web-security
You can view a full list (as of when it was posted!) of command line options for chrome here.
No. Sorry.
Chrome and Firefox, however do support cross-domain requests via the W3C CORS spec (Cross Origin resource sharing) however the remote host has to enable it. If the remote host supports it explicitly then you don't have to make any changes to your XMLHttpRequest to be able to fetch the content.
You can install chrome plugins which enable cross-origin resource sharing .
I use this .