> It appears to me that the cross-origin issue is caused because the plugin > definition is embedded in the WebAdmin host page that is hosted by the JBoss > AS. This then requires that all plugins also exist within the same origin.
Yes, WebAdmin host page is served through Engine JBoss and therefore sits on its origin. WebAdmin host page loads a plugin by creating an iframe element and setting its "src" attribute to HTML page that's responsible for loading the actual plugin code. But if the plugin HTML page originates for a different origin (protocol, domain, port), plugin code that runs within an iframe element is unable to access top-level (WebAdmin host page) pluginApi object, because of Same-Origin-Policy restriction. As Itamar mentioned, we shouldn't deploy custom UI plugins on Engine JBoss, as it would complicate its maintenance from package perspective. There are currently two ways how plugins can be developed, and I'd like to discuss these on the upcoming meeting: --- 1) The "Standard" way: use standard Engine servlet (PluginSourcePageServlet in PoC) to take care of rendering plugin HTML page. This servlet will pick up all plugin dependencies, plugin configuration and actual plugin code, and produce the resulting HTML page used to load the plugin. Because this servlet runs on Engine JBoss, there will be no cross-origin issues. Pros: - well-defined way how to develop plugins (separation of dependencies, configuration and actual plugin code) - no need to take care of producing HTML plugin page (servlet will take care of that) Cons: - doesn't support custom plugin bootstrap schemes (e.g. cannot use GWT to develop plugins) - due to Same-Origin-Policy, plugin can communicate with Engine (e.g. REST API), but not with other external services (on other origins), unless you implement cross-origin communication schemes such as JSONP --- 2) The "Custom" way: run your own application server, deploy your plugin code there (client JavaScript code, plus optional server code). Instead of using standard Engine servlet, use your own application server to serve plugin HTML page. This means that you are responsible for assembling everything (plugin dependencies, configuration, code, etc.) into HTML page used to load your plugin. Pros: - supports custom plugin bootstrap schemes (e.g. can use GWT to develop plugins), since you are responsible for providing plugin HTML content - supports hosting custom server-side plugin code (in addition to plugins being able to call Engine through APIs like REST) Cons: - to work around Same-Origin-Policy (and get hold of WebAdmin's pluginApi object), your application server needs to use CORS (Cross-Origin Resource Sharing), which basically means extra HTTP response header --- Originally, I wanted to start with (1) (the "Standard" way), but we should discuss and evaluate both approaches. Vojtech ----- Original Message ----- From: "George Costea" <george.cos...@netapp.com> To: "Vojtech Szocs" <vsz...@redhat.com>, "Itamar Heim" <ih...@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Monday, July 23, 2012 3:33:12 PM Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Rather than extending the WebAdmin page with javascript, would it be possible to instead have an API that modifies that page with extensions? For example, the API tells it to add a new menu item that when launched would invoke the url registered with the extension. The new page is now rendered in a distinct window (much like early versions of GWT hosted mode created an embedded browser window). -George -----Original Message----- From: engine-devel-boun...@ovirt.org [mailto:engine-devel-boun...@ovirt.org] On Behalf Of Vojtech Szocs Sent: Monday, July 23, 2012 8:27 AM To: Itamar Heim Cc: engine-devel Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" <ih...@redhat.com> To: "Vojtech Szocs" <vsz...@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <eco...@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content >> via a servelt. > > If the GWT UI plugin web application won't be deployed on Engine JBoss AS > instance, we'll run into cross-origin iframe communication issues that we'll > need to deal with. we'll need to solve these in any case for plugins which do have an existing external service. > > In other words, why prevent others to "keep away" from Engine JBoss AS > instance? Why not let them deploy whatever they want next to engine.ear, > given that they are doing this on their own responsibility? because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework. > >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or >> the REST API. > > This was actually option [1] as described in my email below. > > From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI > plugins written in GWT, however, can include server-side logic on their own. > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Vojtech Szocs" <vsz...@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" > <eco...@redhat.com> > Sent: Monday, July 23, 2012 11:54:14 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>> this implies server side code running on the engine, >> >> Actually, yes and no :) let me explain: >> >> - UI plugins developed in GWT need some context (plugin web >> application deployed next to engine.ear) from which their code will >> be served > > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via > a servelt. > >> - UI plugin web applications can contain only static resources (HTML + >> generated JavaScript) -> answer is "NO" >> - UI plugin web applications can also contain server-side code (e.g. for GWT >> RPC) -> answer is "YES" > > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or > the REST API. > >> >>> which has additional implications on compatibility vs. ui plugins as >>> discussed >> >> I don't think we need to worry about this :) >> >> If a GWT UI plugin web application needs to use Engine functionality, it can: >> >> - use REST API from within UI plugin (JavaScript) code [1] >> - use REST API from within its server-side (Java) code [2] > > again, if we want to discuss an approach to making ui plugins which > need server side cooperation not in a separate container of their own > choice, different server, etc. - we can, but lets separate the > discussion on the two. > >> >> [1] - will be supported by UI plugin infrastructure [2] - not >> supported by UI plugin infrastructure >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" <ih...@redhat.com> >> To: "Vojtech Szocs" <vsz...@redhat.com> >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" >> <eco...@redhat.com> >> Sent: Monday, July 23, 2012 9:10:07 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>> Last but not least, writing plugins in Google Web Toolkit (GWT) >>> should be as easy as providing your own plugin source page. Just >>> deploy your GWT plugin application on JBoss AS (next to engine.ear), >>> and point to GWT plugin application host page. >> >> this implies server side code running on the engine, which has >> additional implications on compatibility vs. ui plugins as discussed >> so far which would be java script (I'm not against using GWT for them >> if the resulting java script can be packaged for use as a UI plugin, >> but sever side code i prefer to be isolated from engine until we'll >> define engine plugins). >> >> > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
