Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What are the risks of using iFrame as a temporary migration step for an internal web application?
Overview
Our development team is currently trying to develop and migrate a Web application that is split in two:
- legacy: ASP.NET MVC 5, jQuery, old-style JS programming overall
- "next": Angular SPA + ASP.NET Core 5
Each application has its own domain, but they are accessible only internally (VPN, A/D authentication).
For entire new modules, it is simple as we develop them directly in the "next" version (the user has a unified UI).
However, a recent request deals with important changes done to a part of an entity that affects a tab within a bigger view. As we like to push the migration to the "next" version, we thought of rewriting the entire tab in the next application:
- use an iFrame that loads the "next" application
- the URL provides a query parameter that makes the "next" application to hide the header, navigation, footer and some margins
- iFrame is a temporary (several months - one year) solution until we have the time and budget to migrate the entire view
Research
iFrame seems to work with a few glitches (the content flickers a little bit when loaded), but I am wondering if we risk having big issues when using this. Various articles do not seem to favor iFrame usage. The downsides I have compiled:
- security risk. In our case, both applications are accessible internally only and both require A/D authentication (Windows and Azure A/D respectively).
- usability issues. Never been a focus for the application
- SEO. Again, internal application, so it does not matter
- permalinks - not required in our case
- authentication - in some cases the iFrame might require the authentication again, but this is a known side effect since the application is already split in two
- communication - communication between the iFrame content and the outer functionality is quite small (we just need to know when a save is ready to reload some information).
- browser support - we only target Google Chrome and the only limitation seems to be not allowing downloads in iFrames.
I cannot find any blocking issues, but most information I could find is rather old and maybe some new restrictions are in place / scheduled.
After further testing authentication becomes an issue because Azure A/D msal library does not play nice when user must be unauthenticated. I have used a workaround to have the user authenticated before the view containing the iframe is loaded.
1 answer
I think a lot of the bad press about iframes stems from W3C deprecating them in HTML 4 strict mode, which caused the herd of web developers to internalize that iframes are bad and should be avoided.
However, this deprecation was due to accessibility concerns that have long since been resolved, and HTML 5 restored the iframe to good standing. Unfortunately, news of this reversal was less widely shared than the original deprecation notice, so many people still vaguely remember that something is wrong with the iframe (and make up all sorts of stories why this is so ...)
With that out of the way, let's tackle some of the misconceptions you found:
If you create an iframe, your site becomes vulnerable to cross-site attacks.
Nonsense. iframes are subject to the same origin policy, and communication between them can only happen if both browsing contexts cooperate.
It tends to break the browsers' "Back" button.
What? A back button works just fine on all browsers I ever tested.
It confuses visually impaired visitors, using screen readers.
That stopped being true over a decade ago.
It confuses users, suddenly opening the iframe content in a new browser window.
I have never seen that happen. And I have used iframes in an app used by tens of thousands of people, so if that was a problem, some users would have reported that.
Content within the iframe doesn't fit in and looks odd.
That depends on how that content is styled. Sure, you don't get visual consistency for free, but if you use the same styles inside and out, users won't notice a difference.
Actual problems
The only problem I actually had with iframes was sizing: The size of iframes is determined by their enclosing document, not the document they contain. Relatedly, iframes have their own scroll bar if their content overflows, rather than being scrolled with their parent document. This may or may not be a problem in your case.
iframes for migration to SPAs
We also used iframes for an incremental migration, and it worked well. However, we preferred embedding server generated documents into the SPA rather than the SPA into server generated documents, because the latter causes reinitialization of the SPA framework upon every page navigation.
That is, we preferred to migrate from the outside in, rather than the inside out, by first migrating the global nav to angular and its router. To ensure deep linking capability, we made the angular view include the corresponding server side view, and notified the angular router about server side navigation events by means on an onload script in the server side template.
0 comment threads
0 comment threads