[Engine-devel] UI Plugin API improvements
Hi guys, I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. Modal dialog API ================ Function improved: showDialog New signature: showDialog(title, dialogToken, contentUrl, width, height [, options]) Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ], // Default value = false resizeEnabled: true, // Default value = true closeIconVisible: true, // Default value = true closeOnEscKey: true }); Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) -- New function: setDialogContentUrl New signature: setDialogContentUrl(dialogToken, contentUrl) Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/') -- New function: closeDialog New signature: closeDialog(dialogToken) Example usage: closeDialog('my-dialog') Tab API ======= Functions improved: addMainTab & addSubTab New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) Example usage: // Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); // Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true }); -- Regards, Vojtech
Hi Vojtech, Thanks a lot for the information. Are these changes already available in latest nightly repository or do I have to fetch them from git? As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think? Thanks, René -----Original message-----
From:Vojtech Szocs <vszocs@redhat.com> Sent: Thursday 28th March 2013 16:25 To: engine-devel <engine-devel@ovirt.org> Cc: Keith Robertson <kroberts@redhat.com>; Spenser Shumaker <sshumake@redhat.com>; Christopher Morrissey <christopher.morrissey@netapp.com>; René Koch <r.koch@ovido.at> Subject: UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech
On 03/30/2013 03:12 PM, René Koch wrote:
Hi Vojtech,
Thanks a lot for the information. Are these changes already available in latest nightly repository or do I have to fetch them from git?
As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think?
interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version. but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X. so just wondering: - do you see uiplugins distributed as rpms or some other way? - do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc. Thanks, Itamar
Thanks, René
-----Original message-----
From:Vojtech Szocs <vszocs@redhat.com> Sent: Thursday 28th March 2013 16:25 To: engine-devel <engine-devel@ovirt.org> Cc: Keith Robertson <kroberts@redhat.com>; Spenser Shumaker <sshumake@redhat.com>; Christopher Morrissey <christopher.morrissey@netapp.com>; René Koch <r.koch@ovido.at> Subject: UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Sorry for my late answer - I'm quite busy at the moment. On Sun, 2013-03-31 at 01:30 +0300, Itamar Heim wrote:
On 03/30/2013 03:12 PM, René Koch wrote:
Hi Vojtech,
Thanks a lot for the information. Are these changes already available in latest nightly repository or do I have to fetch them from git?
As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think?
interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version.
This means for example to use %post section and patch the installed files according to the oVirt version? Or require min. version of oVirt in SPEC file and create multiple RPMs: ui-plugin-1.0-1.ov32.el6.noarch.rpm => Requires: ovirt-engine >= 3.2 ui-plugin-1.0-1.ov33.el6.noarch.rpm => Requires: ovirt-engine >= 3.3
but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X.
Exactly - either make it only available if engine version is >= X or provide a workaround if possible (depending on the importance of this feature).
so just wondering: - do you see uiplugins distributed as rpms or some other way?
I'll distribute my plugins in RPM and src form for download. What I'm doing in general (not done yet for my first UI plugin, but will follow): - use autotools for ./configure; make; make install ./configure will allow you to set www document root and some other settings. - create RPM from SPEC
- do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc.
I prefer one codebase for max. 2 or 3 oVirt version and branch each release. e.g: ui-plugin-1.0.x => includes code for oVirt 3.2 and oVirt 3.3 ui-plugin-1.1.x => includes code for oVirt 3.2, 3.3 and 3.4 and tag each release. More then 3 oVirt version aren't maintainable and this doesn't make sense as there want be bug fixes from oVirt team for these old version (I think). But always requiring the latest oVirt version for latest UI plugin version is also not the way I want to go, as I know that it takes some time to upgrade to newer oVirt version... I personally prefer to check UI API version in source code and decide what to do over other methods like multiple RPMs or %post patch scripts... Regards, René
Thanks, Itamar
Thanks, René
-----Original message-----
From:Vojtech Szocs <vszocs@redhat.com> Sent: Thursday 28th March 2013 16:25 To: engine-devel <engine-devel@ovirt.org> Cc: Keith Robertson <kroberts@redhat.com>; Spenser Shumaker <sshumake@redhat.com>; Christopher Morrissey <christopher.morrissey@netapp.com>; René Koch <r.koch@ovido.at> Subject: UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hi guys,
Are these changes already available in latest nightly repository or do I have to fetch them from git?
These changes are already present in oVirt git "master" branch, so if your current work branch is based on "master", you can fetch these changes via "git fetch && git rebase origin/master". (No need to download and apply patches manually from git web interface, as these patches are merged already.)
As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think?
You're right, this is something I've been thinking about lately as well. Since UI Plugins is oVirt feature, we can have two levels of versioning: * level-1 = oVirt version, e.g. "3.2" * level-2 = UI Plugin feature/API version, e.g. "1" [the number always goes up, i.e. new oVirt release does *not* reset this number] As Itamar mentioned below, UI plugins distributed as RPM packages can use "level-1" version to make sure that given plugin is installed only for supported oVirt version.
From UI plugin perspective, "level-2" version would be used to determine actual API compliance. For example, plugin descriptor could specify supported API version(s):
[file:/usr/share/ovirt-engine/ui-plugins/showcase.json] { "name": "showcase", "apiVersion": "xxx", "url": "/webadmin/webadmin/plugin/showcase/start.html", "resourcePath": "showcase-files" } [/file] In the example above, "apiVersion" could follow interval-like syntax, similar to [http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]: * "[2]" --> apiVersion == 2 * "[2,3]" --> 2 <= apiVersion <= 3 * "(2,)" --> 2 < apiVersion Such API compliance checking could be done early on during UI plugin discovery process, with "apiVersion" attribute being optional within the plugin descriptor. (If not specified, the plugin meta-data & configuration would be always sent alongside WebAdmin, just like today.) As suggested by René, there would still be an API function to determine current UI Plugin API version. This could be used to support situations like "plugin supports version 2 and above [via apiVersion], but for version 3 it needs to do something differently".
- do you see uiplugins distributed as rpms or some other way?
We should make RPM packaging a good habit (best practice?) documented on oVirt wiki, but IMHO oVirt version ("level-1") is not enough, we should also track feature/API version ("level-2") separately. Example: * oVirt version 3.2 --> feature/API version 1 * oVirt version 3.3 --> feature/API version 2 (For RHEV, where backports are important, we could have multiple feature/API versions within a single RHEV version.)
- do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc.
IIUC this can be covered with combination of "apiVersion" + runtime API like api.getVersion(). So guys, what do you think? Regards, Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "René Koch" <r.koch@ovido.at> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Saturday, March 30, 2013 11:30:49 PM Subject: Re: [Engine-devel] UI Plugin API improvements On 03/30/2013 03:12 PM, René Koch wrote:
Hi Vojtech,
Thanks a lot for the information. Are these changes already available in latest nightly repository or do I have to fetch them from git?
As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think?
interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version. but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X. so just wondering: - do you see uiplugins distributed as rpms or some other way? - do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc. Thanks, Itamar
Thanks, René
-----Original message-----
From:Vojtech Szocs <vszocs@redhat.com> Sent: Thursday 28th March 2013 16:25 To: engine-devel <engine-devel@ovirt.org> Cc: Keith Robertson <kroberts@redhat.com>; Spenser Shumaker <sshumake@redhat.com>; Christopher Morrissey <christopher.morrissey@netapp.com>; René Koch <r.koch@ovido.at> Subject: UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Great job on the dialog support, Vojtech! It's working very well for me. I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening? -Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Thursday, March 28, 2013 11:25 AM To: engine-devel Cc: Spenser Shumaker; René Koch; Morrissey, Christopher Subject: [Engine-devel] UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hi Chris, with patch [1] merged recently, default REST API session timeout is explicitly set to 180 minutes. First, please check <session-config> in: * $OVIRT_HOME/backend/manager/modules/restapi/webapp/src/main/webapp/WEB-INF/web.xml * $JBOSS_HOME/standalone/deployments/engine.ear/restapi.war/WEB-INF/web.xml (Both should contain <session-timeout> set to 180.) When making REST API request, make sure not to accidentally close the session: * set "JSESSIONID" cookie for "/api" path * set "Prefer:persistent-auth" header --> without this, REST API session will perform logout after processing request If you still experience timeouts: * make REST API request that includes "Session-TTL:30" --> enforce timeout 30 minutes Let me know how it goes. [1] http://gerrit.ovirt.org/#/c/13044/ Regards, Vojtech ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Vojtech Szocs" <vszocs@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Cc: "Spenser Shumaker" <sshumake@redhat.com>, "René Koch" <r.koch@ovido.at> Sent: Wednesday, April 3, 2013 1:17:31 AM Subject: RE: [Engine-devel] UI Plugin API improvements Great job on the dialog support, Vojtech! It's working very well for me. I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening? -Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Thursday, March 28, 2013 11:25 AM To: engine-devel Cc: Spenser Shumaker; René Koch; Morrissey, Christopher Subject: [Engine-devel] UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Just to reply to my own question, I've done some further investigation and it appears that the session wasn't timing out. It looks like the request from the heartbeat itself was causing the session to be invalidated and a new session to be created. When I modified the code to stop the heartbeat I was able to use the session without problem. Looking at the requests from the browser, it appears that Jboss is creating a new session with each request. I'm guessing this is a side effect of a combination of the basic authentication information in the header and the server essentially re-authenticating on each request and generating a new session ID to prevent session fixation security issues. Has anyone else used the REST session ID that is provided through the plugin API? Have you run into this issue? I think the overall issue is exacerbated by the fact that we are making calls outside of the context of the client from our server and don't have the basic authentication header information. Because the client has this, all requests are re-athenticated whether the REST session ID is valid or not. My calls are getting blocked. Any ideas on how to fix this? A change in the Jboss settings maybe? -Chris
-----Original Message----- From: Morrissey, Christopher Sent: Tuesday, April 02, 2013 7:18 PM To: 'Vojtech Szocs'; engine-devel Cc: Spenser Shumaker; René Koch Subject: RE: [Engine-devel] UI Plugin API improvements
Great job on the dialog support, Vojtech! It's working very well for me.
I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening?
-Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Thursday, March 28, 2013 11:25 AM To: engine-devel Cc: Spenser Shumaker; René Koch; Morrissey, Christopher Subject: [Engine-devel] UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Thanks Chris, this is very useful information! I'm aware of the issue with heartbeat request performing re-login on server [1], the issue you encountered confirms that the root cause is the way how heartbeat requests are made from WebAdmin client (browser). I suspect this has to do something with cookies, i.e. JSESSIONID cookie for /api path used to transmit REST API session ID. I need to check that the browser eventually sends this cookie alongside Prefer:persistent-auth header within the heartbeat request. Handling cookies is always problematic in JavaScript, as WebAdmin code (i.e. /webadmin) cannot get/set cookies for different paths (i.e. /api) and therefore must rely on browser-specific cookie handling for all outgoing requests. This is quite important issue, I'll look into this next week. Again, many thanks for the feedback. [1] https://bugzilla.redhat.com/906046 Thanks, Vojtech ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Vojtech Szocs" <vszocs@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Cc: "Spenser Shumaker" <sshumake@redhat.com>, "René Koch" <r.koch@ovido.at> Sent: Friday, April 5, 2013 4:11:56 PM Subject: RE: [Engine-devel] UI Plugin API improvements Just to reply to my own question, I've done some further investigation and it appears that the session wasn't timing out. It looks like the request from the heartbeat itself was causing the session to be invalidated and a new session to be created. When I modified the code to stop the heartbeat I was able to use the session without problem. Looking at the requests from the browser, it appears that Jboss is creating a new session with each request. I'm guessing this is a side effect of a combination of the basic authentication information in the header and the server essentially re-authenticating on each request and generating a new session ID to prevent session fixation security issues. Has anyone else used the REST session ID that is provided through the plugin API? Have you run into this issue? I think the overall issue is exacerbated by the fact that we are making calls outside of the context of the client from our server and don't have the basic authentication header information. Because the client has this, all requests are re-athenticated whether the REST session ID is valid or not. My calls are getting blocked. Any ideas on how to fix this? A change in the Jboss settings maybe? -Chris
-----Original Message----- From: Morrissey, Christopher Sent: Tuesday, April 02, 2013 7:18 PM To: 'Vojtech Szocs'; engine-devel Cc: Spenser Shumaker; René Koch Subject: RE: [Engine-devel] UI Plugin API improvements
Great job on the dialog support, Vojtech! It's working very well for me.
I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening?
-Chris
-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Thursday, March 28, 2013 11:25 AM To: engine-devel Cc: Spenser Shumaker; René Koch; Morrissey, Christopher Subject: [Engine-devel] UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new.
Modal dialog API ================
Function improved: showDialog
New signature: showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ],
// Default value = false resizeEnabled: true,
// Default value = true closeIconVisible: true,
// Default value = true closeOnEscKey: true });
Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature: setDialogContentUrl(dialogToken, contentUrl)
Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature: closeDialog(dialogToken)
Example usage: closeDialog('my-dialog')
Tab API =======
Functions improved: addMainTab & addSubTab
New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true });
--
Regards, Vojtech _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (5)
-
Itamar Heim -
Morrissey, Christopher -
René Koch -
René Koch (ovido)
-
Vojtech Szocs