I have to include an external whitelabel site within an iframe on my page. There are numerous pages on the external site and they vary considerably in height.
I need to adjust the height of my iframe to accommodate this.
I can get the height of the first page loaded into the iframe (using PHP), but no way of getting subsequent page heights because no way of knowing what the url/location changes to in the iframe.
As this is an external url in the iframe the usual security limitations apply, therefore ALL solutions must come from the parent frame. Solution must be workable on FF and IE at least.
The only think I can think of is to test whether the scrollbars are visible on the iframe, but this is seemingly impossible in these circumstances.
If anyone can prove me wrong, or has any other javascript/ajax/php cross-browser solution I'd love to hear it.
It is not possible to do this because of the browser's security model. If it was possible, that would be a security problem and would have to be fixed.
Although letting the embedding site know the height of a third party webpage when embedded in the page seems harmless, this can leak information to the embedding site that the browser's user wants to keep private. For example, http://www.facebook.com/ renders differently depending on whether or not you are logged in, so if my website can work out the height of <iframe src="http://www.facebook.com/"> then I can work out whether or not you are a facebook user, something you probably don't want me to know.
The information leakage would be similar to the infamous CSS History Leak in that it would reveal information about the user's relationship with the third-party site just by "linking" to that site (in this case with an iframe instead of a link). Browser vendors had to plug the CSS History Leak, so I suspect if you could work out the height of a third party site rendered in an iframe in any browser, the vendor would have to fix that too.
The information leaked would be anything that can be inferred from the height of a page when rendered for a user using their cookies (which the browser will send even though rendering in an iframe inside a different domain's page). The specific risks depend entirely on the nature of the embedded site being "attacked". E.g. I could get an idea of how much stackoverflow activity someone visiting my site has by getting the height of https://stackoverflow.com/reputation which is different for different users.
Related
I have an iframe.
I want to prevent access from the parent document into the iframe from css selectors and other manipulation.
How can I secure it?
You could kill a goat under the light of a full moon inside a pentagram made of salt. If you did that, css or js wouldn't be able to affect the contents of an iframe.
They wouldn't affect them if you didn't either.
You have to explicitly allow sites to interact with the contents of an iframe, either by setting up an api like this, or by setting up cors headers to allow interaction. According to other answers on this site, if the iframe and parent have the same domain, cors rules don't apply, so changes can be made. If you are embedding an iframe from your site on your site, you should probably trust your own code.
If you are asking how to prevent users from using the developer tools to mess around with your iframe contents, you can't. There are all sorts of things that website designers have tried to do to keep me from looking at their source. I've never found one that can keep me out.
I'm looking for the best way to keep a WebRTC video stream + the stream controls (hang up, mute etc.) loaded and active, even if the user navigates to another subpage through the navigation menu.
I thought of the following way, however I don't know if this is the most practical one or if there's a better solution to this nowadays: I'd simply make a wrapper with the navigation menu and put an iFrame where currently the content is. The video stream itself would go in the menu bar itself (it's a sidebar which is wide enough to do something like this), when the user clicks on a menu item, the iFrame src is replaced with the new URL.
Is this the right way to do this? If so however, since I haven't used iFrames that much so far, I have a few more concerns:
Are there any drawbacks as for browser features when using iFrame? For example, I know that Chrome asks you to put several features into the allow attribute of the iFrame, for example when using the camera, microphone or location of the user. Is there anything I absolutely cannot do in iFrames?
Do iFrames share the (PHP) session and cookies with the "main" wrapper, or are those separate sessions?
And probably my biggest concern: How could the JavaScript codes of the wrapper and the iFrames communicate with each other? For example, how could I send a hangup-signal to the video stream in the wrapper from within the iFrame?
Thanks for any hints!
Iframes could work.
Are there any drawbacks as for browser features when using iFrame?
The main issue is that you don't really get control over the presentation of the page while that iframe loads. Users may see a brief moment of solid white, for example, while the previous page is torn down and replaced.
Is there anything I absolutely cannot do in iFrames?
Iframes are pretty flexible. Just keep in mind that they have their own JavaScript context so there is some extra code you need to write to shuffle data back and forth.
Do iFrames share the (PHP) session and cookies with the "main" wrapper
Yes
How could the JavaScript codes of the wrapper and the iFrames communicate with each other?
You can actually access the Document object for the iframe from the outer iframe. (Assuming they're on the same origin, of course.)
const iframe = document.querySlector('iframe');
iframe.contentDocument.querySelector('body').whateveryouwant
Probably the best way though is to use the postMessage API. This allows you send data back and forth as-needed, in a nice isolated way.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
My website offers rich content to users. I often subscribe to third party vendors whose content I embed in my pages. How can I safely embed external domain's content on my webpage in an iframe without worrying that they won't be able to bust out of frame. They won't do it purposely (without risking their clientage/reputation). However, since they almost always are small shops, they become a juicy targets for an attacker who wants to deface/redirect my website.
I am not asking how can I prevent an iframe to access parent frame's DOM, which I know it can't. I am asking how can we prevent an iframe to stop doing something like the following (which doesn't require access to parent's DOM):
top.location=url
Is there a header (something similar/opposite to X-Frame-Options) which I can use on my parent page to ensure that the iframes I embed can't bust out? Remember, I can't ask vendors to add headers/scripts to their pages. They never purposely want to do nefarious things to my page. The scenario I am trying to cover is the one when they get hacked.
As noted in the comments, sandbox attribute can prevent the script inside the iframe to access the windows top.href, location.href and similar methods. This will do what I want to achieve.
From w3schools:
When the sandbox attribute is present, and it will:
prevent the content to navigate its top-level browsing context
I am a complete beginner web it comes to web development which is why I can't actually implement any of the solutions I have found so far.
I essentially wish to display content from one of my sites on another. Please assume for now that this second/host site is a local html page and the first/parent(is this right?) site is http://www.mydomain.com
My only other requirement is that the solution should work on Chrome and preferably other modern browsers.
Thanks in advance.
--EDIT--
By resizing iFrame I mean that I want an iFrame that will either:
i) automatically set itself to the browser's size (actual usable space not window itself) + refreshes every 1 second
ii) change its height based on content being accessed from a different domain
Is there any reason to NOT have a webpage retrieve it's main content on the fly?
For example, I have a page that has a header and a footer, and in the middle of this page is an empty div. When you click on one of the buttons in the header, an http GET is done behind the scenes and the .innerHTML() of the empty div is replaced with the result.
I can't think of any reason why this might be a bad idea, but I can't seem to find any pages out there that do it? Please advise!
It's not unheard of, but there are issues.
The obvious one is that some users have javascript turned off for security reasons, and they will not be able to use your site at all.
It can also negatively impact handicapped users that are using assistive technology such as a screen reader.
It can make it harder for the browser to effectively cache your static content, slowing down the browsing experience.
It can make it harder for search engines to index your content.
It can cause the back and forward buttons to stop working unless to take special steps to make them work.
It's also fairly annoying to debug problems, although certainly not impossible if you use a tool such as Firebug.
I wouldn't use it for static content (a plain web page) but it's certainly a reasonable approach for content that is dynamically updated anyway.
Without extra work on your part it kills the back and forward history buttons, and it makes it difficult to link to the pages each button loads. You'd have to implement some sort of URL changing mechanism, for example by encoding the last clicked page in the URL's hash (e.g. when you click a button you redirect to #page-2 or whatever).
It also makes your site inaccessible to users with JavaScript disabled. One of the principles of good web design is "graceful degradation"--enhancing your site with advanced features like JavaScript or Flash or CSS but still working if they are disabled.
Two considerations: Search engine optimization (SEO) and bookmarks.
Is there a direct URL to access your header links? If so, you're (almost) fine. For example, the following code is both SEO friendly and populates your page as you desire:
Header Link
The catch occurs when people attempt to bookmark the page they've loaded via JavaScript... it won't happen. You can throw most of those potential tweets, email referrals, and front page Digg/Reddit articles out the window. The average user won't know how to link to your content.
Where did you read it is a bad idea? It purely depends on requirements whether or not content will be populated on-the-fly. In most cases, however, the content is loaded along with the page not on-the-fly but if you need your content on-the-fly, it shouldn't be a bad idea.
If your content is loaded via javascript and javascript is disabled on users' browser then definitely it is a bad idea.
I cant think of a bad reason for this either (other than possibly SEO), one thing that would probably be a good idea is to load the data only once. ie
Show Div1 - do ajax/whatever only if the innerhtml is blank
Show Div2 - do ajax/whatever only if the innerhtml is blank
<div1></div>
<div2></div2>
This should keep the server load down so the divs content is only loaded once.
Cheers
This is pretty standard behavior in ajax enabled sites.
Keep in mind however that extra effort will be needed to:
ensure the back button works
link to (and bookmark) specific content
support browsers with javascript disabled.