Check URL in IFrame

[Deadweight]

So currently I am working on something that converts a string of text into another string of text; however, if there are URLs contained in the text it will update the string. EG create it a link then convert it upon hovering it will load a live preview.
The problem happens when the website (eg facebook.com) redirect into another place. EG http://www.facebook.com/ --> https://www.facebook.com/
I am trying to read the url of the iframe after it loads. You can test it here: http://thebcelements.com/portfolio/Live_Preview/.

How can i read the url after it loads.

[jscheuer1]

Can't. You can read the src attribute. However, if what you describe is directed by the remote server, the src attribute will not have changed. For example, using facebook as suggested, I get this in the console:

$('iframe').eq(0).attr('src') // iframe as an iframe element on the page
"http://www.facebook.com/"
window.frames[0].location.href // iframe as a member of the parent window's frames collection.
VM814:2 Uncaught DOMException: Blocked a frame with origin "http://thebcelements.com" from accessing a cross-origin frame.(…)

You MIGHT be able to read the load event of the iframe as an element on the page, or even the iframe as a frame of the parent window, but neither of those will give you the new URL. That would only be an indication that a new URL had loaded, or that perhaps the original one had reloaded.

[molendijk]

Are you sure that the problem is caused by a redirect? Your test page works alright when I submit URLs that don't have code for breaking out of frames inside them. But if they have that code on the page, like Google and Facebook, your test page doesn't work.
So https://www.facebook.com (which is not redirected onto another place) doesn't work. Not because of a redirect, but because of code for breaking out of frames.

[Deadweight]

The reason why https://www.facebook.com will not work or any https website is that http and https aren't for cross scripting. If that makes sense. Only websites that have the same security will work eg http and http or https and https. That is why 'https://www.facebook.com' wont work on 'http://thebcelements.com/portfolio/Live_Preview/'.
Another idea is to take a screenshot of the url using: imagegrabscreen() in php but sadly that only takes a screenshot of i think your current page.

@jscheuer1 - I figured that it wouldn't work. i tried your way also but was just trying to see if there was another way just in case.

[jscheuer1]

Um, hmm. Arie, I think you are onto something but these sites do not break out of iframes. They actually deny display within an iframe. Last I checked that was at least true of Google. For many years it was not, but then about 3 years back? (my memory as for exactly when these things happen is not the best) But at some point they added a clever (nasty - depending upon your point of view) code that just made the page blank if it was shown in an iframe. I think this even worked if javascript wasn't enabled, if so, it must be server based. Anyways, they went immediately from being the single most iframe friendly search engine on the web, to one of, if not the least. I'm imagining FB is doing something similar.

Regardless, you still cannot get the URL (href) of an iframe via javascript unless it's on the same domain as the page(s)/frame(s) that are asking. The src attribute is another story, but that doesn't change unless directed to do so from the page in which the iframe is an element. And - again, unless that's the same page or domain (the one where the iframe is) that's asking, even that MIGHT not be available. It is accessible in this example though as - A.) It hasn't changed (even if the href or URL has), and B.) There's only one top page and we're it in this case, so own the element attributes of the iframe.

[jscheuer1]

You are also correct https will not give up it's content to an http page. But there may be more to it than that. Certainly is in some cases. That might be it though with FB.

[jscheuer1]

Just checked, Google is now by default also https - so that might be it. Only way to test would be to try from an ssl (https domain). I think I may have one I could try that from as long as I don't leave it up for long.

[jscheuer1]

OK, just tried that, looks like we are both correct, this is what the console showed:

Refused to display 'https://www.google.com/' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

AND, that's even with javascript disabled in the browser.

See also:

https://developer.mozilla.org/en-US/...-Frame-Options

It is server side, just as I suspected.

[molendijk]

So am I right in assuming that there's a problem with the URLs of pages that:
(i) break out of frames;
(ii) deny displaying within a frame for any other reason, for instance, because they set 'X-Frame-Options' to 'SAMEORIGIN' on the server side?
and that there's no problem with the URLs of other pages, like http://dynamicdrive.com?

[jscheuer1]

I don't know about the break out of frames bit. From my understanding, if you're using an iframe with the sandbox attribute set, that's supposed to frustrate the javascript break out of frames strategy (just tested this and it does prevent javascript from breaking out of an iframe). It will not however have any effect on a server side header like X-Frame-Options set to SAMEORIGIN or anything more restrictive. Then there's iii, which I guess would be when attempting to show https content in an iframe on an http page. But, that might actually work (in fact does in limited testing). What probably will not work though (at least not in most cases) is http iframe content on an https page.

I think the main problem here is the X-Frame-Options server side header. Anything else is either just incidental or in fact a red herring.

One further thing on this for now - since headers are dependent upon browser compliance, and only desktop and laptop browsers were rated for this header in the sources I found (all of those complied at least enough to deny viewing pages with these headers in frames and iframes), it is an open question if they will work on other devices (tablets and hand helds).