I have a large set of html files that I keep on my windows 10 system that I have not used in a long time. They use frames and I access them using the file:/// mechanism. These no longer works in firefox or chrome but do work with edge. I believe this is due to cross origin frame problem referenced here
SecurityError: Blocked a frame with origin from accessing a cross-origin frame
The actual error produced is
Uncaught SecurityError: Blocked a frame with origin "null" from accessing a frame with origin "null"
I have moved enough of the pages to aws web space to verify that the pages function correctly when retrieved from a web server.
My question is...
Is there any way I can make this work from my local windows 10 system other than adding a web server to it?
Is there any way I can make this work from my local windows 10 system other than adding a web server to it?
No.
Related
We have app working since almost 2 years. Suddenly I see it stopped loading. Console has below error:
Not allowed to load local resouce
Looks like brsower security is not allowing to load file SourceMap.
I looked at chrome, source map not loading but I can't follow that. As I can't ask my users to change browser settings or not to use chrome
Any possible solution?
I want to create image from my canvas, I'm using kineticjs, but I get error: "Kinetic warning: Unable to get data URL. Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported." I suppose, that it's caused by cross-origin error. In canvas I use localy saved images and address path starts with "file://..". Is there any solution how to create image without apache installing? Thanks.
Your local hard drive is deemed to be "other domain" by browsers and will taint Canvas.
That's a good thing! You don't want malicious code to get at stuff on your personal drive.
Some workarounds:
Install a web server on your computer.
Put your image(s) and all files associated with your web app on the desktop (this may/may not help depending on where you got the images to begin with).
Temporarily host your images on a site that allows anonymous cross-origin access to your images.
I have crawled the web quite a lot these days, but couldn't get any accurate information on how crossdomain.xml files behave in case of 302 redirects; especially with the sandboxes having changed significantly over the last versions!
I am relatively new to flash... so any advice is more than appreciated!
I have been working on a project lately that uses audio streams with some sort of CDN distribution! what happens is that a common url is triggered, and then the user is dynamically redirected to the next best server available. In my case, i have no access at the server side of things (at least not anytime soon). And the only path providing an appropriate crossdomain.xml is the one performing the redirect. All the other dynamic paths provide exclusively content!
http://resource.domain.com (valid crossdomain.xml)
302 => http://dyn1.domain.com/...
302 => http://dyn2.domain.com/...
302 => http://dyn3.domain.com/...
I noticed that flash doesn't care much if i try to load the audio stream with something like...
var req :URLRequest = new URLRequest("http://resource.domain.com");
var sound :Sound = new Sound(req); // ie. effectively playing http://dyn3.domain.com
sound.play();
It gets both redirecting, and streaming done well! and doesn't bother for any crossdomain file and starts playing!
Although when i try something different, like setting up some custom headers to the request and loading the file with URLStream instead, everything gets messy! Well, the redirect gets done, as expected but all of a sudden i need another crossdomain file in the redirected location!
Is there any explanation to whats happening and eventually ways to resolve this?!
Thanks for your time!
It comes as a site question : i noticed everything to work flawlessly while being in the local-trusted sandbox and errors happening mainly if not exclusively in the remote sandbox. is it possible that the local-trusted sandbox doesn't care about crossdomain policy files at all!?
Summary
Add crossdomain.xml to each CDN host or adopt to limited Sound functionality.
Details
SWF files that are assigned to the local-trusted sandbox can interact with any other SWF files and can load data from anywhere (remote or local).
Sound can load stuff from other domains that don't allow access using cross-domain policy with certain restrictions:
Certain operations dealing with sound are restricted. The data in a
loaded sound cannot be accessed by a file in a different domain unless
you implement a cross-domain policy file. Sound-related APIs that fall
under this restriction are Sound.id3, SoundMixer.computeSpectrum(),
SoundMixer.bufferTime, and the SoundTransform class.
Flash in general has pretty complex cross-domain policies but in your case the bottom line is that you'll need to have proper crossdmain.xml on each host except the one that serves the SWF:
3.1. If your file is served from http://resource.domain.com it's not required to have http://resource.domain.com/crossdomain.xml but it's really good to have one.
3.2. You will need to have proper http://dyn2.domain.com/crossdomain.xml explicitly allowing your SWF to access dyn2.domain.com to be able to use URLLoader and other APIs that provide access to raw loaded data.
3.3. There's a reason for these restrictions - cookies (and other ambient user credentials). If Flash would not require proper cross-domains after a redirect, one could access any domain with user cookies attached by simply loading his own redirector first. This means accessing all user cookie-protected data (e.g. mail.google.com) from any SWF on the internet that's running in your browser.
I am trying to store a mp4 video file (rather small ~ 2.5MB) in the local app cache.
Manifest looks like:
CACHE MANIFEST
viddy.mp4
Chrome (22.0.1229.94 m) will log the following in the console:
Creating Application Cache with manifest http://example.net/cache.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 1) http://example.net/viddy.mp4
Application Cache Error event: Resource fetch failed (-1) http://example.net/viddy.mp4
When I click the link right next to the Error it's opening the file quite fine.
My manifest is served with the correct MIME-type (I'm using the HTML5 Boilerplate .htaccess-file) and the video is served Content-Type:video/mp4
Is my file too big? I am perfectly able to cache a 1MB image this way, so I thought filesize should not be a problem? Safari on desktop and iPad does cache the video just fine.
Remark: I have seen this question but it does not cover my problem as the solution seemed to be something Python-related.
Chrome does not allow data to be stored in Incognito Mode.
I experienced similar problem and this is how I solve it. In this case Chrome does not give any helpful information about error. I've tried to load same page in Safari (Mac, but Windows should work as well), and I got description, that response for specified resource returns 302 (Redirect) and HTML5 Application Cache cannot handle it.
In your case it might be the same, but I'd suggest you to enable the sniffer and see, what response you get from your resource. If it's different than 200 - you figured the issue.
P.S. I've cached files up to 32 MB without any problems.
Maybe some of you could have ran into the same problem i did.
Imagine you have a file on your machine: file:///c:\test.html
And you have an IFrame inside of this file. You need to indicate whether the IFrame contents are loaded or no.
Bacically, what we have here:
1. location, href, or any other property is inaccessible from file:/// to http:///, or backwards.
2. you can't fire event from the browser window in iframe, or in opposite direction, unfortunately.
Does this problem have a solution?
P.S.: that's not a hack. it's a real problem. making some interaction from local machine with website integration.
UPD: I kinda figure out why it's forbidden. ANY interaction with local files should be forbidden from the web page. It's kinda cool, i do agree. But isn't a # hashtag something that can't harm anyone? :(
You may find some of these techniques useful: http://softwareas.com/cross-domain-communication-with-iframes
Edit: Per comments below, these techniques don't seem to work when accessing file:///c:\<path>\test.html, whereas they do when accessing http://localhost/test.html.
I think that's because the file protocol is even more restricted by the browser than the http protocol. The MSDN page on the file protocol states:
Internet Explorer 6 Service Pack 1 (SP1) no longer allows browsing a
local machine from the Internet zone. For instance, if an Internet site
contains a link to a local file, Internet Explorer 6 SP1 displays a
blank page when a user clicks on the link. Previous versions of Windows
Internet Explorer followed the link to the local file.
Whatever technique you were using to get some cross-domain communication was probably blocked by the browser because you were using the file protocol.