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?
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.