[Engine-devel] Couple of small Feature Requests
David Jaša
djasa at redhat.com
Fri Oct 19 10:01:52 UTC 2012
David Jaša píše v St 17. 10. 2012 v 10:11 +0200:
> Dead Horse píše v Út 16. 10. 2012 v 21:51 -0500:
> > The point is valid on the random passwords in a secured environment.
> > However that being said the randomly generated password does make it a
> > pain when interacting with HTML5 based clients (SPICE or VNC) or any
> > standalone client for that matter.
> >
You can set custom password using REST API too but REST means you'd need
XHR anyway so using generated passwords is more secure with lesser or
equal pain:
$ curl --cacert .certs/my_rhevm.pem -D - -u djasa at my-domain.example.com:my_ovirt_password -H "Content-Type: application/xml" -H "filter: true" -X POST -d "<action><ticket><value>secret</value></ticket></action>" https://my-engine.example.com/api/vms/ad5f7497-120d-40da-9093-c9c4b8919e50/ticket
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 09:51:26 GMT
Set-Cookie: JSESSIONID=ceH5zj17Gu+BKRztkYSDffHY; Path=/api; Secure
Content-Type: application/xml
Content-Length: 221
Connection: close
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<action>
<ticket>
<value>secret</value>
<expiry>7200</expiry>
</ticket>
<status>
<state>complete</state>
</status>
</action>
David
>
> Web client:
> * if it is integrated with UP/webadmin, the portal should give it
> password in exactly the same as it gives the password to the
> plugin
> * if it is not tied to any portal, then you should be able to
> issue XMLHttpRequest to the REST API asking for password and
> extract the temporary password from the reply (IIUC it has to
> engage rest api anyway to get host/port/sport/ca/subject info)
>
> Standalone application can engage REST too:
> http://cfergeau.blogspot.cz/2012/07/outside-boxes.html
>
>
> > At the very least can this to be made to be configurable? The default
> > can be as is but at the very least allow for configurable VNC or SPICE
> > passwords if so desired..
> >
> > Curiously I know that the Web UI does not allow for this now but is it
> > possible to change the password policies via any existing engine or
> > vdsm configurations/parameters?
> > EG:
> > - default 120 second password re-generation, can this be altered?
> > - fixed vs randomly generated password?
> >
>
> in the REST API, you can configure password validity per request (using
> <expiry> tag)
>
> > A side note are there any plans of the horizon for integrating support
> > or allowing for interaction with HTML5 based clients mostly VNC but
> > with new SPICE HTML5 client?
>
> I seem to recall RFEs for that (both novnc and spice html5) but I've got
> no idea if there is somebody actually working on them.
>
> David
>
> >
> > - DHC
> >
> > On Fri, Oct 12, 2012 at 9:42 AM, David Jaša <djasa at redhat.com> wrote:
> > Hi,
> >
> > Dead Horse píše v Čt 11. 10. 2012 v 12:00 -0500:
> > > Would like to make a couple of small feature requests.
> > >
> > > 1) Allow for the SPICE or VNC password to be set in the UI
> > by admin's
> > > or power users.
> > > Benefit: (Assumes spice SSL has been disabled) allows user
> > or admin to
> > > set a password for access by a standalone remote session via
> > vncviewer
> > > or remote-viewer or the spice html5 implementation which is
> > WIP, or
> > > standalone HW thin client
> > > - This may also assume that vdsm is running with SSL
> > disabled as well
> > > to have had vdsm make the neccesary changes to the qemu
> > spice
> > > configuration
> >
> >
> > Drawback: users can choose repetitive and/or weak passwords.
> > Generating
> > a new random password for each connection is the best thing
> > from
> > security POV in my opinion.
> >
> > >
> > > 2) Display currently configured OR generated password and
> > IP/Port for
> > > either VNC or SPICE console of the VM within the PUP and
> > Admin UI
> > > Benefit: At the very least a standalone remote client can be
> > used to
> > > connect once the password and IP/PORT is known for spice or
> > VNC
> > > - Currently VNC will display a dialog that shows the this
> > info but it
> > > would be more useful to have it displayed in the UI given
> > proper
> > > privilege
> >
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=843397
> > https://bugzilla.redhat.com/show_bug.cgi?id=843410
> >
> > >
> > > 3) Display the UUID of a VM in the Admin UI (similar to the
> > how the
> > > disks tab breaks down and shows DISK UUID mappings)
> > > - Benefit: Easier for administrators to map UUID to VM
> > config file
> > > data in the data stores or export domains
> >
> >
> > IMO full uuid should be displayed in General subtab only
> > because it's
> > too long to have it as a column.
> >
> > It would be nice to see it in a column though in some
> > shortened form
> > because it could probably enable relaxing of
> > unique-name-of-VM-in-whole-setup restriction.
> >
> > David
> >
> > >
> > > - DHC
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> > --
> >
> > David Jaša, RHCE
> >
> > SPICE QE based in Brno
> > GPG Key: 22C33E24
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
More information about the Engine-devel
mailing list