Get url from iframe when origin is not the same - javascript

I want to get the URL from an iframe when the user redirects by clicking links in the iframe. The source of the iframe is not the same as the web application.
For example:
<iframe src="startingUrl" class="embed-responsive-item" id="iframe" sandbox="" allowfullscreen</iframe>
I add a load listener on the iframe to detect when the user redirects to other urls in this iframe:
const iframe = document.getElementById("iframe");
iframe.addEventListener("load", (evt) => {
const location = iframe.contentWindow.location;
console.log(location); // this gives me a Location object where I can see the href property
console.log(location.href); // this gives me a SecurityError: Permission denied to get property "href" on cross-origin object, I also tried to get a copy of the object but that doesn't work either.
});
I know what causes this problem and I also know it is not possible. But I need to find a way to get the current URL of the page. If this is a no go then I want that the user who uses this web application can copy the url of the iframe and put it in an input field.
Now they can do "View frame source" in chrome and This frame: view frame source or info in Firefox. But this is too complicated for the user. Is there a way they can see the URL in the iFrame or a way for the user to get the URL simpler.
The site in the iFrame is not mine.
All help is much appreciated!

Short answer: This is a no go, unless you have the support of the other site in your iframe and they are willing to add the code in #박상수 answer.
Longer answer: You could set up a proxy server to inject the required code to make this work, but then you will run into legal and ethical difficulties, so I am not going to explain how to do that in depth.
Another approach might be to create a browser extension and have your users install that. Again I should point out FaceBook has in the past ran into ethical difficulties taking this approach.
Ultimately their are very good security reasons why the browser stops you doing this and you should probably respect those reasons and not do it.

If you don't see the code below, check the link below.
console.log(iframe.src);
Check out this link
SecurityError: Blocked a frame with origin from accessing a cross-origin frame
let frame = document.getElementById('your-frame-id');
frame.contentWindow.postMessage(/*any variable or object here*/, 'http://your-second-site.com');
window.addEventListener('message', event => {
// IMPORTANT: check the origin of the data!
if (event.origin.startsWith('http://your-first-site.com')) {
// The data was sent from your site.
// Data sent with postMessage is stored in event.data:
console.log(event.data);
} else {
// The data was NOT sent from your site!
// Be careful! Do not use it. This else branch is
// here just for clarity, you usually shouldn't need it.
return;
}
});

You will want to override the error being automatically thrown:
const iframe = document.getElementById('iframe');
iframe.addEventListener('load', evt => {
const loc = iframe.contentWindow.location;
try{
loc.href;
}
catch(e){
if(e.name === 'SecurityError'){
console.log(iframe.src);
}
}
});
<iframe src='https://example.com' class='embed-responsive-item' id='iframe' sandbox='' allowfullscreen></iframe>

Related

iframe content doesn't always load

So I have a system that essentially enabled communication between two computers, and uses a WebRTC framework to achieve this:
"The Host": This is the control computer, and clients connect to this. They control the clients window.
"The Client": The is the user on the other end. They are having their window controlled by the server.
What I mean by control, is that the host can:
change CSS on the clients open window.
control the URL of an iframe on the clients open window
There are variations on these but essentially thats the amount of control there is.
When "the client" logs in, the host sends a web address to the client. This web address will then be displayed in an iframe, as such:
$('#iframe_id').attr("src", URL);
there is also the ability to send a new web address to the client, in the form of a message. The same code is used above in order to navigate to that URL.
The problem I am having is that on, roughly 1 in 4 computers the iframe doesn't actually load. It either displays a white screen, or it shows the little "page could not be displayed" icon:
I have been unable to reliably duplicate this bug
I have not seen a clear pattern between computers that can and cannot view the iframe content.
All clients are running google chrome, most on an apple powermac. The only semi-link I have made is that windows computers seem slightly more susceptible to it, but not in a way I can reproduce. Sometimes refreshing the page works...
Are there any known bugs that could possibly cause this to happen? I have read about iframe white flashes but I am confident it isn't that issue. I am confident it isn't a problem with jQuery loading because that produces issues before this and would be easy to spot.
Thanks so much.
Alex
edit: Ok so here is the code that is collecting data from the server. Upon inspection the data being received is correct.
conn.on('data', function(data) {
var data_array = JSON.parse(data);
console.log(data_array);
// initialisation
if(data_array.type=='init' && inititated === false) {
if(data_array.duration > 0) {
set_timeleft(data_array.duration); // how long is the exam? (minutes)
} else {
$('#connection_remainingtime').html('No limits');
}
$('#content_frame').attr("src", data_array.uri); // url to navigate to
//timestarted = data_array.start.replace(/ /g,''); // start time
ob = data_array.ob; // is it open book? Doesnt do anything really... why use it if it isnt open book?
snd = data_array.snd; // is sound allowed?
inititated = true;
}
}
It is definitele trying to make the iframe navigate somewhere as when the client launches the iframe changes - its trying to load something but failing.
EDIT: Update on this issue: It does actually work, just not with google forms. And again it isn't everybody's computers, it is only a few people. If they navigate elsewhere (http://www.bit-tech.net for example) then it works just fine.
** FURTHER UPDATE **: It seems on the ones that fail, there is an 'X-Frames-Origin' issue, in that its set the 'SAMEORIGIN'. I dont understand why some students would get this problem and some wouldn't... surely it depends upon the page you are navigating to, and if one person can get it all should be able to?
So the problem here was that the students were trying to load this behind a proxy server which has an issue with cookies. Although the site does not use cookies, the proxy does, and when the student had blocked "third party cookies" in their settings then the proxy was not allowing the site to load.
Simply allowed cookies and it worked :)
iframes are one of the last things to load in the DOM, so wrap your iframe dependent code in this:
document.getElementById('content_frame').onload = function() {...}
If that doesn't work then it's the document within the iframe. If you own the page inside the iframe then you have options. If not...setTimeout? Or window.onload...?
SNIPPET
conn.on('data', function(data) {
var data_array = JSON.parse(data);
console.log(data_array);
// initialisation
if (data_array.type == 'init' && inititated === false) {
if (data_array.duration > 0) {
set_timeleft(data_array.duration); // how long is the exam? (minutes)
} else {
$('#connection_remainingtime').html('No limits');
}
document.getElementById('content_frame').onload = function() {
$('#content_frame').attr("src", data_array.uri); // url to navigate to
//timestarted = data_array.start.replace(/ /g,''); // start time
ob = data_array.ob; // is it open book? Doesnt do anything really... why use it if it isnt open book?
snd = data_array.snd; // is sound allowed?
inititated = true;
}
}
}

Get around same-origin policy to get top URL of a page from inside a cross-domain iframe

I've got some code running in an iframe on 3rd-party sites. Some will be directly in the top page, some will be inside another iframe and some of these may be cross-domain. I need to find a way to get the URL value of the top page using any means necessary.
The furthest I can go up due to cross-domain policy is until the browser stops what the code is doing. I catch the error and look at the referrer of the current window context I'm in. Most cases the page above this is the top page, but not necessarily.
The only way I can see around this is building up a list of URLs which I think are the top page, and then sending a bot with a JS browser validate by seeing if the iframe my code got up to was in fact directly nested in them.
That's still not particularly accurate though, and I'm sure there must be another way of doing it...
Thanks to anyone who can help.
There is actually a way to get the domain in both Chrome and Opera, (in multiple nested cross-domain iframes), though it is not possible in other browsers.
You need to use the 'window.location.ancestorOrigins' property.
I have created a snippet of code below, which should work for you and if you think you can improve the code or comments, please don't hesitate to edit the gist on Github so we can make it even better:
Gist: https://gist.github.com/ocundale/281f98a36a05c183ff3f.js
Code (ES2015):
// return topmost browser window of current window & boolean to say if cross-domain exception occurred
const getClosestTop = () => {
let oFrame = window,
bException = false;
try {
while (oFrame.parent.document !== oFrame.document) {
if (oFrame.parent.document) {
oFrame = oFrame.parent;
} else {
//chrome/ff set exception here
bException = true;
break;
}
}
} catch(e){
// Safari needs try/catch so sets exception here
bException = true;
}
return {
'topFrame': oFrame,
'err': bException
};
};
// get best page URL using info from getClosestTop
const getBestPageUrl = ({err:crossDomainError, topFrame}) => {
let sBestPageUrl = '';
if (!crossDomainError) {
// easy case- we can get top frame location
sBestPageUrl = topFrame.location.href;
} else {
try {
try {
// If friendly iframe
sBestPageUrl = window.top.location.href;
} catch (e) {
//If chrome use ancestor origin array
let aOrigins = window.location.ancestorOrigins;
//Get last origin which is top-domain (chrome only):
sBestPageUrl = aOrigins[aOrigins.length - 1];
}
} catch (e) {
sBestPageUrl = topFrame.document.referrer;
}
}
return sBestPageUrl;
};
// To get page URL, simply run following within an iframe on the page:
const TOPFRAMEOBJ = getClosestTop();
const PAGE_URL = getBestPageUrl(TOPFRAMEOBJ);
If anybody would like the code in standard ES5, let me know, or simply run it through a converter online.
Definitely not possible without communicating with some sort of external system. The cleanest/most accurate way to gather data is to get the top window URL if the browser lets you, but catch errors and use the referer with a flag to note it's the referer.

Uncaught SecurityError: Blocked a frame with origin ... from accessing a frame with origin

I've made a component for an SAP solution (whatever) that is embedded into a report through an iframe. After I deployed the report on an SAP plateform (BO), I got this error (on Chrome, but does not work on IE or FF either):
Uncaught SecurityError: Blocked a frame with origin "http://support.domain.com" from accessing a frame with origin "http://support.domain.com". The frame requesting access set "document.domain" to "domain.com", but the frame being accessed did not. Both must set "document.domain" to the same value to allow access.
The iframe is embedded into my component so it's suppose to run on the same domain with same port than report.
I found this post on SO and this one, but it does not really helped me to understand what I need to do.
Is there a way to get rid of this, or at least work around this ?
Thanks :).
EDIT:
Host Page URL : http://support.domain.com/BOE/OpenDocument/opendoc/openDocument.jsp?sIDType=CUID&iDocID=AbmffWLjCAlFsLj14TjuDWg
URL of the file calling a property on the iframe (and generating the error) : http://support.domain.com/BOE/OpenDocument/1411281523/zenwebclient/zen/mimes/sdk_include/com.domain.ds.extension/res/cmp/js/component.js
URL of the frame :
http://support.domain.com/BOE/OpenDocument/1411281523/zenwebclient/zen/mimes/sdk_include/com.domain.ds.extension/res/cmp/js/map/js/map.html
The iframe embed itself some script tag, I can see everything loading fine in the Network tag of the console.
Maybe it can help.
EDIT 2 :
I just realized SAP report is itself embedded into an iframe. That means my iframe is within an iframe, that might be the issue. Still, when lauching the report from Eclipse, everything is working.
I've finally found a solution.
The top of my iframe had a domain.location set to domain.com and my iframe a domain.location set to support.domain.com.
Event though I still think that both belong to the same domain, browsers don't like it it seems so.
Re-setting the domain.location did the work.
To answer the ones asking about how to re-set location.domain, here is the snippet of code my team used to use. This is quite old (2y ago), not really optimized and we do not use it anymore, but I guess it's worth sharing.
Basically, what we were doing is load the iframe with passing it top domain in the URL parameters.
var topDomain = (function handleDomain(parameters) {
if (typeof parameters === "undefined") {
return;
}
parameters = parameters.split("&");
var parameter = [],
domain;
for (var i = 0; i<parameters.length; ++i) {
parameter.push(parameters[i]);
}
for (var j = 0; j<parameter.length; ++j) {
if (parameter[j].indexOf("domain") > -1) {
domain = parameter[j];
break;
}
}
if (typeof domain !== "undefined") {
domain = domain.split("=");
return domain[1];
}
return;
})(window.location.search),
domain = document.domain;
if (domain.indexOf(topDomain) > -1 && domain !== topDomain) {
document.domain = topDomain;
}
The previous answer is no longer valid:
Document.domain - https://developer.mozilla.org/en-US/docs/Web/API/Document/domain
Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
The current solution would be to use message exchanges. See samples on:
The solution is https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Chrome app: accessing sandboxed iframe from parent window

I'm using knockoutjs in my google chrome app. To be able to use knockout, I have to define the real application.html as sandox page and include it as an iframe in a dummy container. Application structure is as follows:
- container.html
|
+-- application.html as iframe
|
+-knockout and application.js
Iframe is defined as follows:
<iframe src="application.html" frameborder="0"
sandbox="allow-same-origin allow-scripts" ></iframe>
Running
document.getElementsByTagName("iframe")[0]
in inspect tool on container.html throws following error.
Sandbox access violation: Blocked a frame at "chrome-extension://hllbklabnppjkmnngfanldbllljfeaia"
from accessing a frame at "chrome-extension://hllbklabnppjkmnngfanldbllljfeaia".
The frame being accessed is sandboxed and lacks the "allow-same-origin" flag.
How can i access the iframed document from it's parent?
Do something like this:
manifest.json
"sandbox": {
"pages": ["my_ui.html"]
}
my_ui.html
<script type="text/javascript" src="knockout-1.2.3.4.js"></script>
<script type="text/javascript" src="my_ui.js"></script>
my_ui.js
this.onSomethingChange = function() {
window.top.postMessage(
{ command: 'please-do-something', myArgument: this.myArgument() }, '*');
};
container.html
<script type="text/javascript" src="container.js"></script>
<iframe id="knockoutFrame" src="my_ui.html"></iframe>
container.js
window.addEventListener('message', function(event) {
var kocw = document.getElementById('knockoutFrame').contentWindow;
var anotherContentWindow = // etc.
var dest;
if (event.source == kocw) {
// The knockout iframe sent us a message. So we'll forward it to our
// app code.
dest = anotherContentWindow;
}
if (event.source == anotherContentWindow) {
// Our app code is responding to the knockout message (or initiating
// a conversation with that iframe). Forward it to the knockout code.
dest = kocw;
}
if (dest == null) {
console.log('huh?');
}
// This makes container.js like a gatekeeper, bouncing valid messages between
// the sandboxed page and the other page in your app. You should do
// better validation here, making sure the command is real, the source
// is as expected for the kind of command, etc.
dest.postMessage(event.data, '*');
}
Your statement "I have to define the real application.html as sandbox page and include it as an iframe in a dummy container" is probably not what you wanted. The idea is to sandbox the smallest possible thing, message out to the gatekeeper page that validates the messages, and have the gatekeeper forward the narrow messages to your un-sandboxed application logic. If you just stuff everything into the sandbox, you're defeating the purpose of the sandbox.
Disclaimer: I haven't carefully examined this code from a security perspective. You'll want to assume that hostile messages are coming from the sandbox (or from elsewhere, for that matter), and do what you can to address that threat.
Found out the culprit. This is my proxy.js, which is included by the container.html, used as a bridge to transfer the messages between the application iframe and the background.js. Following part is the one that listens for the messages originated from the iframe.
window.addEventListener("message",
function(evt){
console.log(evt); <= this is the problem
var iframe = document.getElementById("application").contentWindow; <= not this one
if (evt.source == iframe) {
return chrome.runtime.sendMessage(null, evt.data);
}
}
);
I didn't think that console.log would be the causing the problem. Instead i was suspecting from the document.getElem.. line. Because trying to run that code in inspect window of the application was throwing the same error.
But it seems that console.log (console seems to belong to container.html's scope) accesses some internals of event object that are not meant to be accessible out of the iframe's scope(which explains why i get the same error in inspect console). Removing the console.log line solved this problem for me.

Fake User Agent for iframe

I'm new to Javascript. I have found this code to change user agent using Javascript.
var __originalNavigator = navigator;
navigator = new Object();
navigator.__defineGetter__('userAgent', function () {
return 'Custom';
});
var iframe='<iframe id="frame" name="widget" src ="http://www.useragentstring.com/" width="100%" height="400" marginheight="0" marginwidth="0" frameborder="no" scrolling="no"></iframe>';
document.write("User-agent header sent: " + navigator.userAgent + iframe);
This code works & returns fake user agent, Though how will I set same fake user agent for iframe ?
Here is fiddle of what I'm up to : http://jsfiddle.net/ufKBE/1/
I already answer the same question at <Load iframe content with different user agent>
For your convenient, I copied and paste the answer here:
First of all, you must create a function to change the user agent string:
function setUserAgent(window, userAgent) {
if (window.navigator.userAgent != userAgent) {
var userAgentProp = { get: function () { return userAgent; } };
try {
Object.defineProperty(window.navigator, 'userAgent', userAgentProp);
} catch (e) {
window.navigator = Object.create(navigator, {
userAgent: userAgentProp
});
}
}
}
Then you need to target the iframe element:
setUserAgent(document.querySelector('iframe').contentWindow, 'MANnDAaR Fake Agent');
You may also set an ID to the iframe and target the ID instead of all iframe elements on the page.
That is not the right way to switch your user agent to the faked one. window.navigator = {userAgent:Custom_User_Agent} is just a javascript execution. It will simply be ignored as you refresh the page, either it is on window or within the iframe, and then the default user agent which will be sent to the server instead. If you really want to switch your user agent, it has to be the browser setting you deal with. Some browsers allow this on their settings, and some others include user agent switcher or support some kind of plugin that do this
http://www.howtogeek.com/113439/how-to-change-your-browsers-user-agent-without-installing-any-extensions/
The alternatives are, you can also try to access the website from the server or build your own web accessing application. These ways, you can freely alter your header or use your own customized user agent
Another way is by using AJAX. but of course it is limited by cross-origin-policy

Categories