Stronger Microfrontend isolation/sandbox?

[carvinlo]

New Feature Proposal

For more information, see the CONTRIBUTING guide.

Description

I read your article before, thinking about sandbox isolation. I want to know what you think about the completely isolated sandbox solution, and whether there are other side effects. Such as Qiankun.
What are your thoughts on sandbox and whether they will achieve similar functions in the future, thank you.

Background

[Provide any additional background for the feature, e.g., why is the current solution insufficient, what problem will it solve, etc.]

Discussion

[Optionally, outline any pros and cons you can currently think of to provide the basis for a solid discussion]

[FlorianRappl]

Unfortunately, it is impossible to create a real sandbox without using <iframe>. Even if you use a proxy (which will cripple the perf + is not supported on older browsers) you'll can easily break out by event delegation or other techniques that eventually give you access to the full spectrum.

Right now this is one of the browser API limitations.

We usually recommend using zoid if stronger guarantees are needed.

I'll leave it open - maybe someone has other good insights or ideas.

[FlorianRappl]

I think we can also introduce an optional iframe for stronger isolation here.

We'll need to do a spike regarding this, but from the top of my head the situation would be as follows:

1. Certain pilets (or all) will actually not be loaded directly, but via a special kind of proxy function.
2. The proxy function creates an iframe in which the pilet runs (1 iframe for each proxied pilet).
3. All registrations are done via messaging, with functions / components being proxied with a special message.
4. Functions / components are wrapped by the proxy and - once requested / called - rendered / called in the iframe.
5. We magically place the components from the iframe in the layout. This will be the tricky part.

For this to work the created iframe will have the app shell, too, but running in a special mode that does not load / display the full design, but only bringing the shared dependencies + layout to the pilet.

The advantage of this kind of architecture is that the pilet really does not care if it runs in an iframe or in the full app shell / main frame. It just works. All the proxying / magic is done by Piral.

[FlorianRappl]

Some maybe useful links for getting the components from the iframes embedded seamlessly:

• https://medium.com/better-programming/how-to-automatically-resize-an-iframe-7be6bfbb1214
• https://stackoverflow.com/questions/819416/adjust-width-and-height-of-iframe-to-fit-with-content-in-it

That would, however, require one iframe per component, instead of one iframe per pilet (which may host multiple components).

Are there ways around it?

1. Host an additional iframe per component (i.e., we have 1 + N iframes per pilet, where N is the number of currently active / shown components): PRO: Quite clean, CON: Super complex (a lot of communication / orchestration needed)
   2.Host a single iframe, which spawns the whole page. but is "transparent" and takes the communication with the parent to determine "placeholders" on the parent. PRO: Somewhat clean, CON: Complex layouting
2. Host a single iframe, which is hidden and computes all its styles to inline them etc., then essentially moves the components renderings to the parent frame. This is like server-side rendering, just in the browser. PRO: Clean. CON: Not very efficient.

We'll need to do more thinking here.

[carvinlo]

2. Host a single iframe, which is hidden and computes all its styles to inline them etc., then essentially moves the components renderings to the parent frame. This is like server-side rendering, just in the browser. PRO: Clean. CON: Not very efficient.

Can this solve:

• View size, such as maximize the mask layer of modal dialogs

If the pilet is running in an iframe, do we still need to deal with real-time synchronization of the environment (such as real-time synchronization of cookies) ? Or need to resolve the browser’s security restrictions on iframes? (such as https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery)

[FlorianRappl]

What do you mean with "synchronization of cookies"?

The iframes would be created using srcdoc, however, the pilet's script inside the iframe would still come from whereever the script source is. So in some sense it would be identical to the current solution, however, it would be isolated in the sense that the script cannot manipulate the app shell. All interaction would go via the messaging mechanism involving a Pilet API proxy. No other things can be proxied (e.g., manipulation of window).

[carvinlo]

What do you mean with "synchronization of cookies"?

All requests inside pilet require to carry the token (stored in cookie) after login. If this problem should not exist in non-cross-domain scenarios, please ignore.

The iframes would be created using srcdoc

Will not produce cross-domain, great.

[gregra81]

@FlorianRappl Is the iframe suggestion is something you're still pursuing?

[FlorianRappl]

Yes definitely. It's planned for next year.

[carvinlo]

This is a framework for sandbox isolation through iframe: alibabacloud-alfa
The article: Sandbox implementation of Alibaba Cloud open platform micro front-end solution