What are the risks of using iFrame as a temporary migration step for an internal web application?
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
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.