I'm looking to perform cross-domain requests on my localhost in developer mode. I work on Opera. So I used the following command to disable web security since Opera is based on Chromium:
cd c:\Program Files\Opera\
launcher.exe --disable-web-security --user-data-dir="c:\nocorsbrowserdata"
according to this Stack Overflow question. It did open a new instance of Opera for me with the following message:You are using an unsupporting command-line flag: --disable-web-security. Stability and security will suffer to certify that web security has been disabled. But when I try to perform a cross-domain request, I get CORS related errors. So I tried disabling web security on Chrome thinking it was a browser issue using the following command:
chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security
It gave me the same message as in Opera but I still didn't get there to perform cross-domain queries. I still don't understand because I was certified on several stackoverflow questions that I could make cross-site requests by disabling web security.
I am using the Application Insights JavaScript SDK on my website and Firefox is blocking the requests back to Azure. It is however working on Chrome.
The website is running on https and Application Insights works correctly on Chrome.
On the Console in Firefox I see the following warning:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://dc.services.visualstudio.com/v2/track. (Reason: CORS request did not succeed).
Why is Firefox identifying the request as a blocked CORS request, but Chrome doesn't?
I would like the Application Insights request to succeed from Firefox as well.
Did you installed an ad blocker extension (i.e. uBlock origin)?
If yes, try to disable it.
Couple of points to look at:
Which version are you using for AI. Try upgrading your package to latest one:
You can go ahead try adding the site to exception and see if it works, it could be because of the firefox exception too:
Firefox 'Cross-Origin Request Blocked' despite headers
Last and most importantly check the headers as mentioned by #Bergi in the comment to see if headers are same for both browser.
Additional reference: https://github.com/Microsoft/ApplicationInsights-node.js/issues/133
http://testingfreak.com/how-to-fix-cross-origin-request-security-cors-error-in-firefox-chrome-and-ie/
Hope it helps.
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 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.
I want to develop JavaScript on my Windows machine. Do you know a browser where I can turn off Same Origin Policy so I can develop locally? Firefox would be optimal.
Or if you know a proxy I could use for a SOAP/WSDL site it would be great too.
I am trying to work with the JavaSCript SOAP Client.
UPDATE 6/2012: This used to work at the time of the writing, but obviously no more. Sorry.
In Firefox (might apply to other Gecko-based browsers as well) you can use the following JavaScript snippet to allow cross-domain calls:
if (navigator.userAgent.indexOf("Firefox") != -1) {
try {
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
}
catch (e) {
alert("Permission UniversalBrowserRead denied -- not running Mozilla?");
}
}
It looks like there's an issue created in the Chromium issue tracker for achieving the same functionality, so you could try starting Chrome with the argument --disable-web-security. I don't know which builds this works on exactly, but at least Nokia's WRT Tools comes with a Chrome installation that does in fact allow loading content from other sites.
Unfortunately, using the following:
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
has been disabled in Firefox 5.
https://bugzilla.mozilla.org/show_bug.cgi?id=667312
Make a page on your local server that calls the remote server and answer the same as the remote server.
Example, javascript calls local server for a JSON. The local server makes the call to the remote server for that JSON. The local server receives the JSON from the remote server and send it to the javascript.
Using the Chromium 13.07, you can start it with security disabled:
/usr/bin/chromium-browser --disable-web-security
That's on Ubuntu 11, but change the location as your system.
All of the given answers are good ones when it comes to getting around the same origin policy in production.
For development, there is no convenient way to "disable" this security check. There are workarounds (see other answers) or hacks (you could use Greasemonkey to wrap up the JavaScript and use their GM_xmlhttprequest as a temporary measure), but no way to actually "turn it off" as you describe.
i run this command on mac, it works on me when i use google chrome to run my project.
open -a Google\ Chrome --args --disable-web-security --user-data-dir
I have no real experience with this, but FireFox 3.5 allows Cross-Site JS according to the W3C Cross-Origin Resource Sharing Draft.
See: https://developer.mozilla.org/En/HTTP_access_control
Firefox would be optimal.
If you can live with Internet Explorer, you may be able to use an .hta application
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx
(This is one of the ways the Selenium test automation tool deals with the issue)
In Chrome (& Chromium) 48 and above you should add the flag --user-data-dir like this:
chromium-browser --disable-web-security --user-data-dir
And it works.
You can also redirect a local port to the remote server and port via ssh.