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.
Related
I am currently attempting to wrap a web application (ConnectWise) for inclusion within my company's central intranet site. It's a fairly simple process for the most part; create a containing page, with an iframe, point the iframe at the ConnectWise url. This part works for almost all of the functionality.
The problem comes during certain select features of the app (in this case, part of the process of creating a timesheet entry), which simply fail to work. Chrome gives the following console output.
Uncaught SecurityError: Failed to read the 'frame' property from 'Window': Blocked a frame with origin "https://app.example.com" from accessing a frame with origin "https://host.example.com". Protocols, domains, and ports must match.
I am aware this is caused by the security options for cross-site and same-origin policies. Given the following points, is there a way to overcome this?
I have full control over https://host.example.com
I can change html, javascript, and file contents
I can change IIS settings and headers
I have partial control over https://app.example.com
I can not change html, javascript, and file contents
I can change IIS settings and headers.
I have tried setting the Access-Control-Allow-Origin on each server, which so far is the only method I've come across that does not involve being able to change the file contents for the app server. This does not appear to work when given the settings (and combinations of settings) of
* or https://app.example.com while on https://host.example.com
* or https://host.example.com while on https://app.example.com
Edit:
The solution to this "duplicate" question is not applicable here. I do not have access to change file contents (including javascript) of the iframed page (app.example.com). Additionally, the script requiring the permission to run is the page within the iframe, not the page hosting the iframe.
CORS headers such as Access-Control-Allow-Origin only affect AJAX requests, not DOM access.
However, If they are both on the same domain but different subdomains then you can include the following on each page:
document.domain = 'example.com';
From MDN:
One document is allowed to access another if they have both set
document.domain to the same value, indicating their intent to
cooperate
If app.example.com has any script includes to host.example.com then you could put the above code in those scripts to set the domain.
e.g.
<script src="https://host.example.com/setup.js"></script>
No, it is not possible.
Access-Control-Allow-Origin primarily affects getting raw data from HTTP requests, not live DOMs.
postMessage can let frames on different origins communicate, but it requires JS to be included on both pages.
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).
This is annoying. I am trying to make it so that when the I press F5, the frame reloads. I have got it so that if the focus is on the main page (not the iframe) it works. However, when I try to implement a similar solution or even make any attempt to communicate with the iframe, I get an 'Unsafe JavaScript attempt to access frame'. To be more specific, the exact error is:
Unsafe JavaScript attempt to access frame with URL http://www.spow.tk/projects/test from frame with URL http://spow.tk/projects/Explorer/02/. Domains, protocols and ports must match.
Please help as this really is a pain.
Thanks
Those two sites are on different domains. Due to security restrictions in Javascript, you cannot script across domains. Check out Wikipedia or Mozilla for more info (quoted Mozilla to prevent link rot):
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin. This policy dates all the way back to Netscape Navigator 2.0.
Mozilla considers two pages to have the same origin if the protocol, port (if one is specified), and host are the same for both pages. The following table gives examples of origin comparisons to the URL http://store.company.com/dir/page.html:
URL Outcome Reason
http://store.company.com/dir2/other.html Success
http://store.company.com/dir/inner/another.html Success
https://store.company.com/secure.html Failure Different protocol
http://store.company.com:81/dir/etc.html Failure Different port
http://news.company.com/dir/other.html Failure Different host
There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks. For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page would pass the origin check with http://company.com/dir/page.html. However, by the same reasoning, company.com could not set document.domain to othercompany.com.
Port number is kept by the browser separately. Any call to the setter, including document.domain = document.domain causes the port number to be overwritten with null. Therefore one can not make company.com:8080 talk to company.com by only setting document.domain = "company.com" in the first. It has to be set in both so that port numbers are both null.
spow.tk and www.spow.tk are considered to be different domains.
One thing you can do however, is to force your site to use one or the other, so that this issue doesn't arise again. For instance, if you're using Apache, you can modify your .htaccess to redirect all requests from spow.tk to www.spow.tk (or www.spow.tk to spow.tk if that's what you prefer). Even if your users or code reference one domain, the request will be redirect to the domain you specified.
I have a website and my domain is registered through Network Solutions (who I would not recommend). I'm using their Web Forwarding feature which allows me to "mask" my domain so that when a user visits http://lucasmccoy.com they are actually seeing http://lucasmccoy.comlu.com/ through an HTML frame. The advantages of this are that the address bar still shows http://lucasmccoy.com/.
The disadvantages are that I cannot directly edit the HTML page in which the frame is owned. For example, I cannot change the page title or favicon. I have tried doing it like so:
$(function() {
parent.document.title = 'Lucas McCoy';
});
But of course this gives me a JavaScript error:
Unsafe JavaScript attempt to access frame with URL http://lucasmccoy.com/ from frame with URL http://lucasmccoy.comlu.com/. Domains, protocols and ports must match.
I looked at this question attempting to do the same thing except the OP has access to the other pages HTML whereas I do not.
Is there anyway in JavaScript/jQuery to make a cross-domain request to the DOM when you don't have access to that domain? Or is this something browsers just will not let happen for security reasons.
No. Most browsers implement the same origin policy.
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