I am building a web app to be locally hosted on a Kindle Fire HD 10, in an area (an open-air museum) that does not have internet access.
All files and libraries have been loaded onto the device, and I am using Firefox to access the app. The app consists of locally-hosted javascript files for a panorama Javascript library (https://pannellum.org/), images, css files and an index.html file.
I am able to successfully point to the index.html file on the Kindle Fire through the browser, and load the app. However, I am not able to load the panorama images, and receive this CORS-related error in the console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///E:/The%20Pith/Consultancy%20Projects/Boscobel%20Photo%20Sphere/panoramas/introroom.jpg. (Reason: CORS request not http).
I originally received this on desktop, but was able to change circumvent it by changing the strict_origin_policy setting on Firefox. But this does not seem possible on Firefox Android.
Is there a way that I can do this otherwise (perhaps through Javascript, or through the of my HTML file?
Update: Based on Callum Morrisson's comments below, there does not seem to be an easy solution to this.
Related
I have a local node js server that when I run it on my desktop, website loads correctly. Problem is when I run the server on my laptop I get these errors on opening website.
How can it be that on desktop and on heroku server it's working correctly but not locally on my laptop?
PS: I have never used meta to set CSP or manifest.json or anything like that, as I don't know why it should not work without those settings just like on desktop. I also have a valid SSL certificate created with mkcert just like on my desktop.
As of Chrome 46, inline scripts can be allowed by specifying the base64-encoded hash of the source code in the policy. This hash must be prefixed by the used hash algorithm (sha256, sha384 or sha512).
See this link for more informatio.
If you have a need for some external JavaScript or object resources, you can relax the policy to a limited extent by allowlisting secure origins from which scripts should be accepted.
Your Explorer wants to ensure that executable resources loaded with an extension's elevated permissions are exactly the resources you expect, and haven't been replaced by an active network attacker. As man-in-the-middle attacks are both trivial and undetectable over HTTP, those origins will not be accepted.
I am attempting to build a tiny browser-based app which will run from a file: URL without using a server. (So I can just drop the files on a flash drive, and launch it by just double-clicking the HTML file.) The app needs to read another file, but each approach I attempt to use yields a CORS error.
My two approaches have been:
Make an AJAX request
Load the content into an iframe and try to read the document
which yield the following errors, respectively:
Access to XMLHttpRequest at 'file:///PATHHERE' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
SecurityError: Blocked a frame with origin "null" from accessing a cross-origin frame.
Per MDN's definition of an origin:
Two URLs have the same origin if the protocol, port (if specified), and host are the same for both.
Based on that definition, any file: URL should be same-origin and hence CORS (being cross origin) would not apply.
I found that MDN has a an additional page about file: URLs which states that the desired file must be in the same or subdirectory of the page's file to be considered same-origin. I found that is true for Firefox, but Opera, Chrome, and Safari appear to not follow that idea but rather treat all file: URLs as cross-origin, even if the page is trying to load a copy of itself!
So I could just only use Firefox, except the catch is the file I'm trying to load is a directory and Firefox treats directory listings as cross-origin even if it is a subdirectory of the directory where the original page lives. The error is "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///myapp/subdir. (Reason: CORS request not http)." (Although I would content that it is not cross-origin, therefore shouldn't have to be HTTP.)
So is there any way in any current major browser (preferably Chrome since it would be available everywhere I'd want to use this) to get a directory listing over a file: URL?
And if not, is there any good reason why that's not supported, at least for directories under the folder where the page was loaded from? As in, is there some security reason for it that just isn't obvious to me? Or is it just the general bias against file: URLs? (i.e. that any real app would be hosted on a webserver.)
This is a security feature of internet browsers. Reading a file with file:/// protocol is a big security problem. That is why it is not allowed.
If you still want to read local file in your html page, you can use electron.js - it uses a different approach.
https://electronjs.org/
I'm trying to load an external website on a page and interact with the content, for example add event listeners (for the content of the external site loaded). This won't work on an iframe as I can't interact with the content, I tried to do it using react, and when I want to add event listeners to the iframe I get the following js error Uncaught DOMException: Blocked a frame with origin "http://localhost:3000" from accessing a cross-origin frame.
I thought it was just not possible but then I saw this video from a tool that seems to do that: https://youtu.be/qinZviJajcw?t=21
Does anyone have an idea on have this could be accomplished?
thanks!
By the looks of it, you do not have Cross-Origin Requests (CORS) setup. For ASP.NET, check the following:
https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.1#setting-up-cors
Specifically, you will need to modify the Startup.cs file to enable CORS.
If you are not using ASP.NET, then I recommend that you Google CORS for whatever web back-end you are using.
This is CORS origin problem in JQUERY that restrict DOM to create html element. Please Suggest me solution. In safari if I Disable Cross Origin Ristriction in Works Well.
I have a NodeJs Rest WebService hosted from ec2 responde Json. I use this in a Static Page using Jquery and JavaScript and Deploy on Amazon S3 bucket. But WebService calling not working there but it Works Properly from system folder to Browser. I added bucket policy etc properlly on s3 bucket.
Please take a look here http://docs.aws.amazon.com/AmazonS3/latest/UG/EditingBucketPermissions.html at "Add a Cross-Origin Resource Sharing (CORS) configuration" section.
I have been trying to get this to run correctly so days now with no luck.
I have created a custom audio player, that accesses an MP3 on a S3 Amazon server. The audio player has custom controls enabled by Javascript, and a Audio Visualizer made possible by the Web Audio API.
Now the problem I am running into is this: Work fine on Chrome. Safari out right says it can't run the Web Audio API, but the audio will still play. In Firefox, the entire thing shuts down. Click play... nothing. I thought it was a CORS issue, so we set the proper headers on the server and still nothing. BUT... if I deactivate the Web Audio API visualizer, then I can get the player to play just fine.
http://jsfiddle.net/murphy1976/yqqf7uL1/1/
Here is my jFiddle. I have separated the Audio Player controls Script from the Visualizer Script with comments so you can see how it will work in Firefox, and how it will NOT work in Firefox.
I read somewhere that this issue that I'm running into MAY be a bug with Firefox. I just want to make sure so that I can stop beating my skull over this.
Could I put a call to CORS here?:
<source crossorigin="anonymous" src="audioFiles/35022797.mp3" id="srcMP3" type="audio/mp3">
The same-origin policy says that scripts run on some origin cannot read resources from another origin. (An origin is a domain, plus a scheme and port, like http://foo.example.com:80.)
Note that the same-origin policy does not prevent cross-origin media from being displayed to the user. Rather, it prevents scripts from programmatically reading cross-origin resources. Consider the <img> tag: a page on example.com can show a cross-origin image from other.com, but a script on example.com's page cannot read the contents of that image. The user can see it; the page cannot.
The Web Audio API can read the contents of audio files. If an audio file is from a different origin, this kind of reading is not allow by the same-origin policy. A user can listen to a cross-origin audio file, but a script on the page cannot read the contents of the file. When you attempt to feed a cross-origin audio file into an analyzer script (e.g., so that you can draw a visualization on a canvas), the same-origin policy should stop you. You are attempting to violate the same-origin policy, and the browser is correctly stopping you by refusing to play the audio in way that would allow you to read the file contents.
Note that Chrome does not prevent such cross-origin file reading for audio files, and this is incorrect behavior.
The correct solution is to have your media servers serve the audio files with a CORS Access-Control-Allow-Origin: * HTTP response header. However, this currently does not work in Firefox, which is incorrect behavior. If Firefox hopes to have a compliant implementation, this will be fixed eventually.
Confirmed that there is a bug in Firefox for using the createMediaElementSource method on a cross domain source:
https://bugzilla.mozilla.org/show_bug.cgi?id=937718