2

I am on a team that is interested in using ui:include to embed external resources in a HTML document. While investigating how to do this, I came across this post: JSF Facelets how to include external html?

BalusC clarifies that is the wrong tool for embedding external resources in a HTML document and suggested using iframes instead. My question is: why is it the wrong tool?

The team I'm on is especially concerned about security. The content is all going to be our own, but there is a concern about cross-site scripting when communicating between iframes. I've read that there are security benefits to using iframes, as well.

Since the answer likely depends on the use case, I will describe mine:

We're using a docking framework called wcdocker (http://docker.webcabin.org/), which allows panels to be added as divs (planning to use ui:include) or via iframes.

From what I've read/experienced so far, my main concern is that you would have to load the entire page for a given panel, even if the user might not actually open it. There will be multiple dockers, and each will have about 50 panels that can be opened. I am concerned that the client will be overwhelmed, compared to a simple link that may/may not be opened in the given docker.

My second concern is with conflicts if the user attempts to open the same panel twice (same ID tags, omnifaces socket conflicts where the backing bean declares a PushContext for a viewscoped recipient, etc.). I have read workarounds for some of this, sounds like a headache...

Their main concern is regarding communication between panels and cross-site scripting attacks. They believe the user's panel communication should be done directly on the client side, so that the server does not have to be hit at all. I believe the user's panel communication should be done on the server side via a custom publish/subscribe approach (not via JMS) where panel A publishes to a custom Java "topic" object and panel B subscribes to that topic.

For context, there will be a maximum of 50 users at a time, and the web application will be fairly complex.

Clink
  • 41
  • 5

1 Answers1

2

After a lot of research, there is at least one issue with my question: our content will not be "external" at all. It will be content that resides on the same server as the main application.

Anyway, it seems that at least one concern with iframes is having too many view states. This thread is the most relevant to that problem: JSF multiple views limit. There is a limit to the number of views (15): (ViewExpiredException after upgrade to jsf2) You can increase that limit in the web.xml file, but it may be difficult to identify the right number for the problem described above.

In another thread, BalusC indicates that ui:include is the best way to put an xhtml inside another xhtml (How to include another XHTML in XHTML using JSF 2.0 Facelets?). However, ui:include does not appear to be ideal for dynamic content. With wcdocker, a panel may be added/removed at any time. It may be worth using jquery's load method as an alternative. See this thread for more information, even though it's for PHP's ui:include: Best way of loading/including content? (jQuery's load() vs. PHP's include())

For anyone interested in using wcdocker in a JSF project while avoiding iframes, this code is a good starting point:

    myDocker.registerPanelType('My Panel', {
        onCreate: function (myPanel) {
            var $mydiv = $('<div id="div1"></div>');
            myPanel.layout().addItem($mydiv, 0, 1).css('text-align', 'right').stretch('1%', '');
            myPanel.on(wcDocker.EVENT.LOADED, function() {
                $("#div1").load("thepage.xhtml");
            });
        }
    });

Finally, you may still run into an issue with conflicting id's, particularly if you load the same page twice. This thread may help you to resolve that concern, and it may even be wise to determine ID by a url parameter: Avoiding duplicate ids when reusing facelets compositions in the same naming container

Clink
  • 41
  • 5