I'm developing a mobile app which runs a simple HTTP server and a WebView. The WebView displays an external website which should access the server via javascript (GET). Unfortunately this doesn't work and I assume it's due to the same origin policy but the console doesn't show any errors. I had a similar error before which required me to define "Access-Control-Allow-Origin: *" on the server side. This error already took a while to find because there were no error messages (Firebug "Net" tab showed a completed GET request with empty "response" data). Now I assume a same origin policy violation in the external script, but it's hard to tell because of the missing error messages. The only "hint" I see is in Firebug "Net" tab, showing a connection which "never completes". I checked the packages sent to localhost but there wasn't even a connection attempt => thus I assume the browser is holding it back.
How do I display Javascript "same origin policy" violation errors in Firefox (ext: Firebug, Webdeveloper)?
Firefox(3.6.20 and Chrome) throws an error on XMLHttpRequest cross domain violations. These errors can being silenced by try{...} catch(ignore){} blocks. If you know the actual path of the request you can check in the Firebug's "Net" tab, all the requests(even those denied by "same origin policy") show in the "All" section, and in the "XHR" section those denied by "same origin policy" don't.
Related
I am trying to serve GeoServer WMS service locally on top of Openlayers. I encounter an error that says Cross-Origin Read Blocking (CORB) blocked cross-origin response. How can I serve the Web Map Service layers locally or disable the CORB?
If you suspect Chrome is incorrectly blocking a response and that this is disrupting the behavior of a website, please file a Chromium bug describing the incorrectly blocked response (both the headers and body) and/or the URL serving it. You can confirm if a problem is due to CORB by temporarily disabling it, by starting Chrome with the following command line flag:
--disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
Source: https://www.chromium.org/Home/chromium-security/corb-for-developers/
I am running into a bug in a complex frameset in a complex code base, where I receive the javascript error:
This is being triggered when trying to access the document value of the cross origin frame.
Uncaught DOMException: Blocked a frame with origin "https://originA.com" from accessing a cross-origin frame.
Is there any way that I troubleshoot this error and determine what the second origin is (not originA)? This error is vague and trying to access the .location property of the frame also gives the same error.
I also tried to launch Chrome with --disable-web-security to try to troubleshoot, but the same error was thrown.
All I would like is a clue of what exactly this cross-origin frame that is trying to be accessed is.
I was able to workaround this in Firefox. When I used Firefox and downloaded a "Cors Everywhere" extension, this did still not enable the functionality, but the console error details reported the frame's URL, helping me identify the problem.
I'm using Google Chrome and Adblock Plus.
Firstly, I opened https://www.google.com.sg/ with Chrome and then open a console and input window.open("https://www.google.com.sg/") in the console.
Then a new window will appear. I input window.opener.document in the new window's console, but it throws an error:
"Blocked a frame with origin "https://www.google.com.sg" from
accessing a cross-origin frame."
I am quite confused because I'm using same-origin frame (Both window are from the same origin "https://www.google.com.sg") instead of cross-origin frame.. Why does the brower still complains about the Security Error?
I have an AngularJS/Cordova app which polls a JSON service on a remote server:
$http({method: 'GET', url: 'http://example.com/index.php'})
Developing in the browser and running off my intranet apache server (http://dev) I get "No 'Access-Control-Allow-Origin' header is present" so I fix this by adding:
Header set Access-Control-Allow-Origin "http://dev"
All works fine, and I see Origin:http://dev in my Chrome dev tools.
So, having to think about this for the first time, I wonder what the Origin will be when the app runs in the Android/iOS webviews. I decide to do a build and deploy on my devices and expect to see the same error in remote debugging (Safari for iOS and Weinre for Android), but to my surprise it works (without sending any CORS headers)! I also find that in both devices the app runs in the webview under the file:// scheme, rather than (what I assumed) a http server of some sorts provided by the phone OS.
So research seems to suggest that CORS is not required for file:// - such a "site' may access any XHR resource on any domain. But, when I test this on desktop browsers I find that while Safari does not need CORS for file:// but Chrome does, and FireFox works either way without CORS
So my questions:
1) why is my app working without CORS in Android/iOS - is it because CORS does not apply to file://, or, is Cordova doing something to make it work in the device?
I have <access origin="*"/> in my config
2) if, pending answers to Q1, I should want to be on the safe site and explicitly allow requests from apps, what value do you give Access-Control-Allow-Origin for file:// "hosts"? in my debugging there is no Origin header in the requests from file://
3) in addition to blocking the XHR request to the remote server, Chrome is also blocking my app templates (I'm using separate files), see below. Is this a potential issue with my app, or just a Chrome issue that I do not need to worry about?
XMLHttpRequest cannot load file:///Volumes/projects/phonegap/www/templates/tabs.html. Cross origin requests are only supported for HTTP.
There are two ways for CORS headers to signal that a cross-domain XHR should be allowed:
sending Access-Control-Allow-Origin: * (allow all hosts)
put the host you would like to allow into the Origin header by your backend
As for the file:// URLs they will produce a null Origin which can't be authorized via the second option (echo-back).
As mentioned:
Cross-domain policy does not apply to PhoneGap (for a variety of reasons, basically because your app is essentially running off the file:// URI on-device).
Please be aware that you will have to set up a whitelist for your apps to access these external domains.
As for the Chrome problem, which can be seen in the developer's console:
Failed to load resource: net::ERR_FILE_NOT_FOUND file:///C:/2.html
XMLHttpRequest cannot load file:///C:/2.html. Received an invalid response. Origin 'null' is therefore not allowed access.
there was a discussion on Chromium project's issue tracker, #40787. They mark the issues as won't fix as that behaviour is happening by design.
There is a workaround proposed to simply switch off CORS in Chrome for development purposes, starting chrome with --allow-file-access-from-files --disable-web-security
e.g. for Windows
`C:\Users\YOUR_USER\AppData\Local\Google\Chrome\Application\chrome.exe --allow-file-access-from-files --disable-web-security`
Here is some more cordova related answer:
CORS and phonegap apps
Domain whitelisting in Apache Cordova - a security model that controls access to outside domains.
Check these resources for more info on CORS:
Cross-Origin resource sharing and file://
A nice CORS tutorial: http://www.html5rocks.com/en/tutorials/cors/
Working around origin policy
HTTP access control (CORS) (Mozilla)
Check also Browser support for CORS:
http://caniuse.com/#feat=cors
And for the record formal CORS specification on W3C :)
I have a website that uses the Facebook login button and
connect.facebook.net/en_US/all.js
As of friday, I started getting a cross-origin security error when new users were trying to log in.
Uncaught SecurityError: Blocked a frame with origin "https://www.facebook.com" from accessing a frame with origin "http://www.facebook.com". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.
Instead of redirecting after login, the dialog box just turns to a blank white screen.
This is only happening in Chrome. Everything runs smoothly in Safari and Firefox.
Anyone else experiencing these issues?
Any ideas about a possible fix?