I'm using a third party app which in its current beta status unfortunately lacks customizations options for the iframe integration of that service.
Since the iframe is coming from their website, I can't manipulate it using jQuery.
I understand the reason for all these security measures, but I still need to ask: is it possible to work around this limitation?
I have read about faking the iframe src and redirecting it to your own webserver, essentially creating a new iframe with the same content. Are such things possible or is it impossible what I'm trying to do?
Yes is possible, although depending on what you're doing it could be considered bad form, or a nasty hack. Here's a lib for NodeJS that will help with doing it.
https://www.npmjs.com/package/node-inject
Related
I am working on a Facebook iFrame application, and have a question about styling.
I want the application content to look like the rest of facebook. So the most obvious approach I could think of was to use a stylesheet provided by Facebook for application development that includes such styles. However I cannot seem to find anything about this on developers.facebook.com or any other site for that matter.
I have created some FBML application earlier, and these was able to use Facebook styles directly since the application content was rendrered within the facebook pages. But iframes does not inherit the stylesheet from the parent content (nor should they), so I was wondering how (or possibly if) this can be done.
I have found some posts/blogs that simply tells you to create an application stylesheet that mimics the Facebook look. But I don't think this is a very good idea, as this CSS must be updated every time anything changes on Facebook. It also seems that all facebook wiki pages regarding CSS (which I have used before) has been removed.
The reason I do not want to use FBML Canvas is that Facebook is in the process of deprecating this approach. They recommend new applications to be created using iframes.
http://developers.facebook.com/docs/reference/fbml/
I really hope anyone has any good ideas on this.
There is no official way. For some reason, FB shards their styles to a ridiculous degree. They also change the filename rather than appending a version parameter every time they make a change to prevent downstream caching. Here's an example of todays stylesheets:
http://static.ak.fbcdn.net/rsrc.php/y-/r/40PDtAkbl8D.css
http://b.static.ak.fbcdn.net/rsrc.php/yE/r/u7RMVVYiOcY.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/P-HsvhlyVjJ.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/CFyyRO05F0N.css
http://static.ak.fbcdn.net/rsrc.php/y0/r/k00rCIzSCMA.css
http://b.static.ak.fbcdn.net/rsrc.php/yv/r/BJI6bizfXHL.css
http://b.static.ak.fbcdn.net/rsrc.php/yD/r/rmbhh_xQwEk.css
http://b.static.ak.fbcdn.net/rsrc.php/yn/r/xlsrXFt9-vD.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/Uuokrl6Xv3c.css
http://b.static.ak.fbcdn.net/rsrc.php/y0/r/klTGALEjWM8.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/mlYhlJwnCdr.css
http://b.static.ak.fbcdn.net/rsrc.php/yT/r/uFI2FW2LitH.css
http://b.static.ak.fbcdn.net/rsrc.php/yh/r/5Bzj1255G1S.css
http://b.static.ak.fbcdn.net/rsrc.php/yp/r/5UteuBI1b8_.css
You can automate this process fairly easily using either PHP or .NET using existing solutions Minify and Combiner respectively.
A simpler method would be to use the Web Developer toolbar for Firefox, go to Facebook and choose the Web Developer toolbar option to "view CSS" which will bunch all the CSS up for you. Copy and paste it into your own local stylesheet and you only have to update when Facebook makes a major change.
So while there is no simple way (that I am aware of), there are methods for you take care of it in a fairly speedy manner.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For me iframes are pure evil (well, maybe not so pure). They seems to make a lot of troubles. Yes, your whole site will load once and then you can just load single pages. But people invented AJAX for this purpose.
One of the biggest issues I found with iframe was that I couldn't paste a link to one of the subpages, because the URL never changed (yes, I know there is a workaround for this). Second thing, web search engines may have problems indexing such pages.
Sometimes the accessibility of this sites are worse and some browser can even display them improperly.
There are better ways to design layouts without iframes. Everyday I can see some one asking at SO questions, like "How to access iframe with jQuery?".
So what are the benefits of iframes? What reason can it be to still use them? I just would like to know why.
I can think of 2 reasons (at the moment) why people would still use iframes instead of AJAX:
1) Iframes circumvent the cross domain origin policy (images, scripts, and styles do not). This can be useful for pulling in sites / content from other domain names relatively safely. Basically, this allows the advantage of being able to visually show data from other domains without letting them stomp all over your page with unlimited access (like something like JSONP would be able to do).
2) You can load multiple types of resources from within an iframe, not just certain mime-types (you're relatively limited to application/javascript, application/x-javascript, text/css, text/xml, image/png, image/jpeg, image/gif with scripts, XHR, images, and sources). For instance, if I want to show you a PDF, I can open an iframe and let the Adobe Reader plugin show you that file. Additionally, in the same domain, if I want to pipeline a script, style, and image all together (inline on the page, image would have to be data URI), I can accomplish this with an iframe (and if it's in the same domain, port, and protocol I can access it with JavaScript as well).
Did you know that Gmail is a set of iframes? The visible part is just clever positioning. Additionally, many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in).
IFRAMEs are used to embed and isolate third-party content into a website.
Most of web advertising solutions are based on iframes - because they give security (cross-domain policy) and isolated rectangle on screen which can be fully managed by third party content and scripting (a common use case is advertisments).
Another modern use of IFRAMES is a management of history (common back button workaround) of AJAX applications.
FRAMEs are poor version of IFRAMES. Their use is declining.
If a user has javascript disabled, iframes will work when ajax doesn't. This is not out of the question, considering that people use things like NoScript.
I use them on ajax websites, when I need to upload files without reloading the page.
I still see iframes being used in large corporations where they provide a single sign on which injects header information about the authenticated user which is then passed, via an iframe, towards the actual application(s). Since the "portal" surrounding the iframe handles all the specific authentication details those applications behind it don't need to have each an implementation for it, making things easier to make for the development team and having a single place to monitor and adjust authentication details of users.
There are plenty of technical reasons to use them (especially the security issue mentioned by Dan Beam).
What you shouldn't do is use iframes “like frames”, doing navigation to new pages by updating the iframe only. As you say, this prevents the navigation from being bookmarkable/linkable, responding to the normal navigation buttons, and providing useful link affordances like open-in-new-tab.
But that's not peculiar to iframes. You can see more and more pages where the navigation is done by fetching new content with XMLHttpRequest and writing it to the main content div's innerHTML. Often this is done with jQuery load() and clever-clever slidey animations. This breaks navigation just as badly as iframe-used-as-frame, or indeed old-school framesets. It's a shame so many web authors are using this tactic believing it to be a super-modern web design methodology, when really it's just a new skin on yesterday's despised framesets.
You can work around it in both cases, but it means you have to store a viewstate in the # fragment identifier part and support proper hash-navigation, which isn't trivial. Even then you've still got problems with non-JS agents like search engines; you end up having to have a parallel ?-based and #-based navigation to support both. It's a pain and most don't bother.
Framesets are outdated as of HTML 5, and sometimes you need to have a frame with another site within a site.
Also AJAX can only do so much. Try uploading a file to a site on another domain through https without an iframe. AJAX won't help you there.
In addition to others reasons, I have one specific usage of iframe in my application. Unfortunately, the target browser in my case is Internet Explorer 6. I need to have a footer and a header that are fixed in my web pages. The main part of this page is scrollable.
However, there is a bug in IE6 where I cannot display a div element on top of select elements using the z-index CSS property. Thus, I need to create an iframe that will be used as a hack to avoid this problem.
Of course, this is a really specific usage of iframe and only concern IE6...
Javascript WYSIWYG Editors use iframes, because that is easiest and best way to make it. For example TinyMCE uses it:
http://tinymce.moxiecode.com/
I was building a social network and i see iframes being useful for widgets to put on other peoples website to show like a mini profile or integrate with the content on a remote server. Seems like the most simple way to build this. I know some widgets use JavaScript. Also with the iframe method the session is the same as visiting the site like normal, so great for like buttons.
Many Formatted Text Editors (e.g. TinyMCE, HTMLArea) are implemented as iframe.
iFrames are okay for some cases, as X-domain-requests, or posting data to a source via parameters. But when I want to access data across domains, I prefer using CSS-files - they can accept params, set cookies, add content to the page (:before & :after) and give a visual feedback.
How can Facebook make work external iFrames? nThat's my quiestion. I have always know that for security reasons, external HTML iFrames (i.e. An iFrame with src attribute different from the actual domain root), but then I realized that Facebook iFrame applications does really work, something that really surprised me because I knew that this functionality would be available only with the HTML5 sandbox iFrame mode, and this method works even in not HTML5 compliant browsers. Can anyone explain that to me? How can I do that?
You can have an iframe that points to another domain, that's not a problem. However, there are restrictions in terms of what scripting you can do between the domains (i.e. javascript in domain A can't talk to javascript in domain B).
Facebook gets around it by using a second hidden iframe and fragment identifiers for IE<8 (and window.postMessage I believe, for IE>=8 and other browsers). It's a fairly common technique for getting unrelated domains talking to each, here's an example I found with a quick google.
I'm not using deep linking, so all the pages/states appear as http://site.com
Is it still possible to implement back functionality in this case? It looks like flex has a browser history feature, but not sure if it would still work given that all the pages are at site.com
The other option is that I would save information in the main file itself so I can go to the last page and retrieve whatever data was on it.
Anyone can advise what's generally the best practice way to handle back functionality?
Unfortunately I don't know of any other way to implement browser history (ie, back/forward) without using deep linking (eg, example.com/#foo). This is how the Flex browser history components implement it.
However, one thing you could do, if you need to keep the URL static, is stick your Flex application in a frame. That way the outter frame would still show example.com while the inner frame is at, for example, example.com/#widget=42.
Check out the Flex docs on Deep Linking and the Browser Manager.
The best practice and generally the only way to do it is to use deep linking.
it's best because the users can add a section of your application to "Favorites" and that's an important feature to have IMHO.
Do you need to keep your website with just http:// site.com or is that just how it looks now because deep linking is not implemented?
Checkout Angela's Accessible Rich Internet Application tutorial which gives instructions on how to quickly and easily set up deep linking using UrlKit. The added bonus of this site is that the tutorial is delivered in the environment described... IE: you can view the source for an "in production" example of the implementation.
are there any reasons not to use iframes at all? I currently use it to load a page from a different server (a sign up page - part of a distributed application) to provide a seamless experience. Is using iframes considered bad practice or is its use OK?
The iframe is a great tool. It enjoys near-universal browser support, it's easy to implement and has a number of useful functions. As with any other HTML element, it can be abused, but wielded intelligently it can play a part in a solid UI.
Some developers might argue to use AJAX instead, and in some situations that may be the more appropriate approach, but AJAX is not a panacea and iframes can be a far simpler implementation which has the same end-result for your users. Do whatever is simplest first, and only change that when you can verify how and why that is not working.
Keep using iframes. Here's an example of why:
The whole Verified By Visa thing really annoys me. I'm happily shopping at some site that I trust, when I'm redirected to some site I've never heard of (not visa.com) and I have to fill in some other form and hope that I get redirected correctly back to the shopping site.
Then recently I was shopping at the John Lewis website, and they brought up the Verified By Visa page in an iframe - wonderful! I'm still looking at the John Lewis site, and all that's happening is I'm being asked for my Verified By Visa password - no problem.
Although as a web developer I know that there's no technical difference between that and a plain old redirect-there-redirect-back, the user experience is so much better!
Pros:
Helps with slow third-party content like badges and ads
Security sandbox
Download scripts in parallel
Cons:
Costly even if blank
Blocks page onload
Non-semantic
Source: Best Practices for Speeding Up Your Web Site
iframes have access to certain properties of the parent document, e.g. redirect the parent frame to a new location using parent.location.href or parent.window.location (IE allows to restrict that).
This is great for phishing attacks when embedding content from other servers (even if you trust that server it might be compromised).
iframes can also be used for a variety of other attacks: IFrames security summary.
With HTML 5 you'll be able to use the cross document messaging API to send messages from window to window, but for now the iFrame is the most viable alternative to any sort of AJAX that requires styling and scripting to load with the data.
If you're looking to just use text data in the iFrame, use AJAX instead. If you want external CSS or JavaScript to work in a protected environment, want styling to start from scratch, or need to access cross domain documents, use the iFrame.
Cons are that the accessibility of iFrames generally sucks, although you can prevent this by making sure that you proceed the iFrame with a notice of external content for screenreaders. Also check the HTML specifications for other ways to make the iFrame more accessible. Other than that and the obvious limitations scripting wise, the iFrame is a great tool is used responsibly and sparsely.
One last note, piling a page full of iFrames is definitely not a good idea, as remember that for each loaded iFrame, a DOM is created, HTML requests are made and document wrappers are instantiated, eating memory and bandwidth in the process. Keep iFrame's to a minimum on the page, and you'll avoid misuing a powerful tool in the HTML aresenal.
IFrames are a great way to "include" external content in a web page. However, there are a couple of (small) drawbacks:
Security sandboxing will cause problems with JavaScript if the IFrame does not originate from the same domain.
You cannot get CSS to co-operate between the IFrame and the parent page, unless you control the stylesheets themselves.
From an indexing point of view, the IFrame's content doesn't exist.
Screen readers might not like the IFrame, for the same reason. Or they won't be able to properly indicate the relative meaning of an IFrame's contents.
Apart from that, they're great! The points I mentioned might even be considered advantages, if you think about it (except the screen reader one): in principle, an IFrame can't influence its parent page's layout, and it isn't influenced itself by its parent either.
As a general rule, iframes are a bad experience for SEO reasons. So, you ask is there any reason not to use iframes? Yes, if you use iframes you are losing some organic placement in the search engines.
Of course, there are usability concerns which can (and should) trump SEO value of pages.