I have a upload script in another host and after remote file upload with Ajax I call a function like this :
echo '<script language="javascript" type="text/javascript">window.top.window.stopUpload('.$result.' , \'res2\' , uploaded , dkey);</script>';
the stopUpload function in the main page should run and do some thing (show pictures and ...)
but I get Permission denied error
Error: Permission denied to access property "stopUpload"
tip : Imagine I have stopUpload function in pageA and I call send file with ajax to upload in my another Host page called pageB I have a stopUpload function in pageB which should run on pageA after upload complete but face to above error ...
Can I call javascript function in another page remotely?
Thanks.
You are probably violating Same Origin Policy.
An Iframe can access parent window content only if they both belong to same origin.
An origin consists of Protocol (http/https), domain name(example.com and port(default 80). If any of these are different then sites are considered from different origins. If you are able to modify content of both the sites then you can manually set the document.domain=domain.com. After that you won't get the error.
#Edit
Both the sites should at least have super domain in common for manual domain setting to work.
For example, facebook.com and google.com can never be compatible since their super domains are different.
However docs.google.com and developer.google.com can be compatible as they have super domain google.com in common.
They both would have to declare document.domain=google.com in a script tag.
Related
Impossible to execute function in Iframe from Parent without the sandbox : allow-same-origin. (when I put it, it works)
But I need to avoid this for the security of my modul.
Blocked a frame with origin from accessing a cross-origin frame
The domain, port and protocol are the same. Only the path to file is different
If you have a server side language skills, you can scrape the url that you want to post to and deliver it locally. Some would call this a router page.
So, myrouter.php receives $_POST['url'], php validates the url through a hash or some other means, then delivers the content to your app. Now you are able to post into the container. Otherwise, and I just digested the rest of your problem, you could use a server side include and "Bam", problem solved.
I have latest version of ckeditor. I did file upload to my remote service. that service after uploading, returns uploaded file link. that is included as iframe 'upload' tab.
So that is all ok. But when I try to switch tab or close image uploader popup window 'ckeditor' throws error:
"Blocked a frame with origin "http://localhost:3101" from accessing a frame with origin "http://localhost:61666". Protocols, domains, and ports must match."
Is where any way to fix this problem?
That is a security standard. Browser auto check and prevent it like default way. Have no method to pass it.
But in your case I have a trick to resolve this problem, you can try this:
After click "send it to server" and receive a response.
Detect your iframe source by id in DOM
Change the iframe's source domain to current domain. (important thing of this trick to pass error "Blocked a frame with origin..." )
And do continue like as you did.
I wrote a chrome extension for a specific website. If the extension is installed and I navigate to that site "example.com", my extension calls the following method:
var search="john";
$.get("https://www.example.com/complete/search?q="+search, function (data) {
console.log(data);
});
That works just fine.
Now I have to call the same method from within the options-page of that extension. When I do that, I receive the following error:
XMLHttpRequest cannot load
https://www.example.com/complete/search?q=John. No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost' is therefore not allowed access.
I understand why this happens but have to find a way to get around this. My idea is to trigger the Extension-Script to call the method and then return the results to the options page. I expect, chrome.runtime.sendMessage() isn't help here.
Needless to say: That domain is not hosted by me, so I can't just change the header.
The error indicates it's not an actual options page: you're opening it (possibly accidentally) through a local webserver (origin: http://localhost/) instead of opening a page packaged with the extension.
You need to add your page (say, options.html) to your extension's folder
You need to add it to the manifest like "options_page": "options.html" or better yet with options_ui
You need to reload the extension to apply the manifest change
You need to open it through the extension, e.g. through chrome://extensions or the context menu of your extension's button (if any)
From the page file://localhost/Users/pistacchio/dev/epress/catflow/test_html/index.html I have the following (coffeescript) code trying to access an iframe:
$('#ipad-viewport iframe').bind 'load', () ->
console.log $(this).contents().find('map')
(This translates to the following javascript, but I don't think the issue relies here):
(function() {
$('#ipad-viewport iframe').bind('load', function() {
return console.log($(this).contents().find('map'));
});
}).call(this);
I wait for the iframe page to be loaded and try to access an element within its body. I get the following error:
Unsafe JavaScript attempt to access frame with URL file://localhost/Users/pistacchio/dev/epress/catflow/test_html/catalogo/catalog/intro.html from frame with URL file://localhost/Users/pistacchio/dev/epress/catflow/test_html/index.html. Domains, protocols and ports must match.
Now, since the iframe is defined like this:
<iframe src="file://localhost/Users/pistacchio/dev/epress/catflow/test_html/catalogo/catalog/intro.html" width="1024" height="768"></iframe>
Aren't both my page and the iframe in the same domain, or file://localhost? Why am I experiencing this problem?
Oh, if relevant, I'm testing this with Chrome 18.
file:/// URLs are subject to a slightly different javascript security policy to the normal same origin policy that applies to hosted content. In order to stop a saved web page from being able to read the entire contents of your disk, different files are seen as different origins. Just fire up a local server and host your content on that; you will fall back to the "standard" policy where origins are defined by domain/ip.
If for some reason you can't run a web server, you may get some mileage out of the
command line switch: --allow-file-access-from-files. I believe this has the affect of making all file:/// URLs to be defined as belonging to the same origin.
For posting AJAX forms in a form with many parameters, I am using a solution of creating an iframe, posting the form to it by POST, and then accessing the iframe's content.
specifically, I am accessing the content like this:
$("some_iframe_id").get(0).contentWindow.document
I tested it and it worked.
On some of the pages, I started getting an "Access is denied" error. As far as I know, this shouldn't happen if the iframe is served from the same domain.
I'm pretty sure it was working before. Anybody have a clue?
If I'm not being clear enough: I'm posting to the same domain. So this is not a cross-domain request. I am testing on IE only.
P.S. I can't use simple ajax POST queries (don't ask...)
Solved it by myself!
The problem was, that even though the correct response was being sent (verified with Fiddler), it was being sent with an HTTP 500 error code (instead of 200).
So it turns out, that if a response is sent with an error code, IE replaces the content of the iframe with an error message loaded from the disk (res://ieframe.dll/http_500.htm), and that causes the cross-domain access denied error.
Beware of security limitations associated to iFrames, like Cross domain restriction (aka CORS). Below are 3 common errors related to CORS :
Load an iFrame with a different domain. (Ex: opening "www.foo.com" while top frame is "www.ooof.com")
Load an iFrame with a different port: iFrame's URL port differs from the one of the top frame.
Different protocols : loading iFrame resource via HTTPS while parent Frame uses HTTP.
My issue was the X-Frame-Options HTTP header. My Apache configuration has it set to:
Header always append X-Frame-Options DENY
Removing it allowed it to work. Specifically in my case I was using iframe transport for jQuery with the jQuery file upload plugin to upload files in IE 9 and IE 10.
I know this question is super-old, but I wanted to mention that the above answer worked for me: setting the document.domain to be the same on each of the pages-- the parent page and the iframe page. However in my search, I did find this interesting article:
http://softwareas.com/cross-domain-communication-with-iframes
Note if you have a iframe with src='javascript:void(0)' then javascript like frame.document.location =... will fail with Access Denied error in IE. Was using a javascript library that interacts with a target frame. Even though the location it was trying to change the frame to was on the same domain as parent, the iframe was initially set to javascript:void which triggered the cross domain access denied error.
To solve this I created a blank.html page in my site and if I need to declare an iframe in advance that will initially be blank until changed via javascript, then I point it to the blank page so that src='/content/blank.html' is in the same domain.
Alternatively you could create the iframe completely through javascript so that you can set the src when it is created, but in my case I was using a library which reqired an iframe already be declared on the page.
Basically, this error occurs when the document in frame and outside of ii have different domains. So to prevent cross-side scripting browsers disable such execution.
if it is a domain issue (or subdomain) such as www.foo.com sending a request to www.api.foo.com
on each page you can set the
document.domain = www.foo.com
to allow for "cross-domain" permissions