search

finos / FDC3

An open standard for the financial desktop.
https://fdc3.finos.org
Other
201 stars 132 forks source link

Question: DOM Projection for UX parts. #1328

Open Davidhanson90 opened 2 months ago

Davidhanson90 commented 2 months ago

Question Area

DOM Projection for UX parts.

In our current implementation we are presenting app resolver UX to the user and we are currently just attaching this to the current apps DOM tree. This is not ideal and I understand that there is a recommendation to use IFrames to attach DOM. My assumption here is that this is to avoid possibly polluting an apps DOM with FDC3 related content.

Now firstly I was wondering if this assumption is correct? Secondly, I was considering that we could launch the app resolver UX in new window instead. Discussing internally I had heard from @Roaders that there could be some concerns around code injection but we were not clear on the details. Can you provide colour here?

Regardless, I was thinking we could take a different approach. Modern browsers (chromium, safari etc) support the adoptNode API

This API allows for DOM projection, therefore you can launch a new window from a parent window, load HTML and CSS into, however all the code an behaviour for the DOM in the child window still fully remains within the parent app. The window is purely a projection with no behaviour. We use this in our web container to support spawing multiple windows and as there is no code being injected into a window anywhere I think it side steps the concerns that may/may not exist.

Therefore, I am thinking that an app which uses a FDC3 web client library already has local code which executes in the context of the app. Using the DOM projection technique we could include web components in the library which are then projected into a new window thus avoiding any changes to the current Apps DOM trees.

There are a number of assumptions I have made here as to the "why" of Iframes so please feel free to correct me and evaluate this idea.

kriswest commented 2 months ago

IFrames were chosen to sandbox the intent resolver (or channel selector) code in its own DOM, we looked at some other form of code injection and decided that it would open up an unacceptable security hole in applications (as it could be abused to inject anything - both unsafe and likely to fragment with non-standard usage). By injecting an iframe, loading it with a DA specified URL and communicating with it via postMessage/MessagePorts its sandboxed and comms with it constrained (necessary for vendor-agnostic comms).

The advantage with the iframe was that it could be displayed within/over the application, which is generally where its expected to be - very much so for the channel selector. However, the iframes are optional - DAs that display apps in iframes in their own windows can of course just display the intent resolver/channel selector over or outside the app's iframe. Launching the intent resolver in a separate window can also be implemented by the DA window (either by loading a URL for the UI or by loading a URL for content that adopts nodes - although this seems more complex) - the trick will be making sure you get positioning right so it's clearly associated with the action that the user took in the application. We tried to be as flexible as possible here to facilitate innovative implementations, but without creating security concerns.

Happy to discuss at a future meeting.

Davidhanson90 commented 2 months ago

Yeah ok this answers my main question which sounds like DOM isolation and security. I do worry about this however

The advantage with the iframe was that it could be displayed within/over the application, which is generally where its expected to be

This is specifically what click jacking protection is for. Are their docs on configuring this as I know in a lot of our applications click jacking protection is often a requirement using X-Frame-Option

kriswest commented 2 months ago

We're planning to raise the FDC3 for the Web proposal in its current form as @experimental so it can be implemented and issues like this explored in implementations. If the approach chosen proves problematic we can change it...

I'm not 100% clear on what you are proposing as an alternative - as you need access to the other document to adopt nodes from it. As we want the Desktop Agent to be able to provide the UI implementations (where needed) it needs to be provided cross-origin, which prevent access to the document... If the DA instead wants to provide a separate window with the UI (and try to display it over the apps window, dealing with getting the permission for a popup of course) they can simply indicate that they don't need the iframes by setting the URL fields null which will prevent injections of the iframes and then do that however they wish. We are already aware that some implementation will load apps in iframes and can display content over the app already, so again they would indicate that they don't need the iframes injected.

Happy to discuss this more - agenda for the meeting on the 19th is going to be full with review of the proposal docs for our first version, so I would suggest we do so at the meeting after (after OSFF).

kriswest commented 2 months ago

@kziemski is this in anyway related to your question about Module federation?

kziemski commented 2 months ago

@kriswest yes/no. this definitely would be the solution to his problem but with a caveat of course of bundling for MF. But MF primary use case is super apps with a host/appremote model and it provides a form for remote module loading in a structured manner. it not just about the ui. i don't want bring it into fdc3 without having a back and forth on future architecture with you guys hence why i spoke up and didn't think fdc3 general was where i want to have that conv. anyway i'll table it for the next call and touch on it briefly there.