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.
Related
Why we do not get access-control-allow-origin issue when we have img tag
src=urlOfdifferentDomain element refers to different domain
like case:1
<img src="urlOfdifferentDomain" />
but we will get same error when we do case 2
//creating image element
a=new Image();
// image on load function
a.onload=function(){
}
// assigning src function
a.src=urlOfdifferentDomain
I just want to know what is the difference between these two approaches .
I also assign csp img-src in webserver to self then also image getting loaded from different domain in case 1
Case 1 is OK because the use of image in HTML does not expose the resource (from other domain) to JavaScript, thus no security problem is caused.
Case 2 will report error because the use of Image object DO bring security risks for some operation such as Canvas editing, as it exposes resource from other domain to JavaScript.
UPDATE: This error is caused by browser security check. The web server doesn't know whether the request comes from html tag or from javascript call, and will return the resource anyway -- you can check the Network debug panel in browser, and see that the resource is downloaded with status 200. After the resource is downloaded and exposed to JavaScript operation. Browser will check whether the JavaScript operation on the resource has vulnerability. If yes, Access-Control-Allow-Origin error will be reported if CORS is not enabled in server.
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.
Hi I am having a problem with this message.
the url from my MAIN page is:
page1.mydomain.com/page1.html
this page have a Iframe to:
frame.mydomain.com/iframe.html
and from the main page I open a window from a another page like that:
mywindow = window.open("http://page1.mydomain.com/page3.html", 'page3', 'status=1,height=768,width=1280,scrollbars=1');
all the 3 pages have set the javascript:
document.domain = "mydomain.com";
I can interact from the main page to the iframe without a problem.
I only have problem to access the window.open properties.
Like:
mywindow.document.getElementById("something")
I got that error message.
blocked a frame with origin from accessing a cross-origin frame
if I try from the page3:
window.opener.document.getElementById("somethingPage1")
I got the same error:
blocked a frame with origin from accessing a cross-origin frame
Why I can interact with the iframe and can't interact with the window.open and the window.opener ?
In my case domain names were different and I solved it by replacing client's domain with the parent's domain name. You can try that if domain name is not matter in child(popup) windows.
What you are trying to access window.opener.document.getElementById() won't work.
It will raise security error as you posted. Best way to do is make both the URLs under the same Domain Name if it's possible. Or just for the development you can install extension
"Allow-Control-Allow-Origin:" in Chrome it will work.
I am using an iframe for a pseudo-ajax file upload. The iframe is in the same view as the upload javascript:
<iframe id="upload_iframe" name="upload_iframe" style="position: absolute; left: -999em; top: -999em;"></iframe>
his works 'nicely' on my local machine, but when I deploy to an Azure web site, I get the following error in Chrome's debug console:
Uncaught SecurityError: Failed to read the 'contentDocument' property
from 'HTMLIFrameElement': Blocked a frame with origin
"https://acme.azurewebsites.net" from accessing a frame with origin
"null". The frame requesting access has a protocol of "https", the
frame being accessed has a protocol of "data". Protocols must match.
I understand this iframe to be same-origin, as it is strictly local, but how do I convince the browser that it is local? That is, is there something I should be doing to the origin and protocol of my iframe to avoid this error?
This is my code, in a nutshell:
dataAccess.submitAjaxPostFileRequest = function (completeFunction) {
$("#userProfileForm").get(0).setAttribute("action", $.acme.resource.links.editProfilePictureUrl);
var hasUploaded = false;
function uploadImageComplete() {
if (hasUploaded === true) {
return;
}
var responseObject = JSON.parse($("#upload_iframe").contents().find("pre")[0].innerText);
completeFunction(responseObject);
hasUploaded = true;
}
$("#upload_iframe").load(function() {
uploadImageComplete();
});
$("#userProfileForm")[0].submit();
};
The form userProfileForm has its target property set to the iframe. This upload arrangement seems to work for most requests, and I don't know if the 'uncaught exception' message is just an observation on Chrome's part, or a potential show stopper. Is there not perhaps a way I can 'catch and ignore' such an exception, and just display a generic message if this happens?
This may depend on your browser, but the IFRAME element is generally not supported for the data protocol, see Wikipedia entry:
http://en.wikipedia.org/wiki/Data_URI_scheme
It may have worked on localhost because localhost can use different authentication & authorization methods (for example on Windows it may run as a trusted site, and may pass your windows user credentials to server automatically, etc.). Same origin I believe means protocol, host, and port must all match. Since data protocol is different than https this is not same origin, hence the security error.
Usually the data protocol is only supported by these elements:
object (images only) (ie: not activeX controls)
img
input type=image
link
CSS declarations that accept a URL
Can you post more of your code and problem statement? There are multiple other ways to accomplish file uploads. For example, traditional POST method (single file), HTML5 method (multi files), or even using javascript to send a stream of bytes to a web service (I did this once in an ActiveX control that used TWAIN to scan documents on user's computer and then upload the scanned image to the website).
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