Ping. On 06/11/2014 06:33 PM, Sheldon wrote:

Now I have send a patch V1, no more comments.

These days, I talk with ZhengSheng about the ticket of VM.

Now we are change our design as follow for we should care the VMs created by other tools.

1. make the ticket as the sub-resource of a VM. support GET(lookup) and PUT(update) method.

2. we will not set expire for ticket.

3. kimchi will set a initial random password for VM when create it.

4. PUT(update) method can set a password for a VM created by other tool. but if expire is set for this VM, kimchi will not change the password. or kimchi can change the password but not change the expire.

5. when GET method to retrieve the password, if the VM is create by other-tools. And expire is set, kimchi raise http 400 error when timeout.

6. pass the ticket to vnc/spice websocket in cookie, not in URL. vnc/spice login page get the ticket from cookie.

-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center

+1 Just one comment below On 06/11/2014 07:33 AM, Sheldon wrote:

Now I have send a patch V1, no more comments.

These days, I talk with ZhengSheng about the ticket of VM.

Now we are change our design as follow for we should care the VMs created by other tools.

1. make the ticket as the sub-resource of a VM. support GET(lookup) and PUT(update) method.

2. we will not set expire for ticket.

3. kimchi will set a initial random password for VM when create it.

4. PUT(update) method can set a password for a VM created by other tool. but if expire is set for this VM, kimchi will not change the password. or kimchi can change the password but not change the expire.

Why not let user update password and expire time?

5. when GET method to retrieve the password, if the VM is create by other-tools. And expire is set, kimchi raise http 400 error when timeout.

6. pass the ticket to vnc/spice websocket in cookie, not in URL. vnc/spice login page get the ticket from cookie.

On 6/11/2014 6:33 PM, Sheldon wrote:

Now I have send a patch V1, no more comments.

These days, I talk with ZhengSheng about the ticket of VM.

Now we are change our design as follow for we should care the VMs created by other tools. If I remember correctly, the ticket is just VNC password.

1. make the ticket as the sub-resource of a VM. support GET(lookup) and PUT(update) method.

where does the VNC password originally stored, please do not duplicate. you have no way to keep it synchronized if duplicate store it. Think about if a user use virt-manager to changed a VM's VNC pass, how can kimchi know it and update accordingly. I feel quite strange to support to get password, I have ever only seen change/reset password. Password is user privacy, assuming that no one has the right to know it. Thinking about security risk. I think the ticket should not be the literal password, it should be an encryption of the password and only the system has the key to decript it.

2. we will not set expire for ticket.

you can set an expire of vnc password, but once it is expired, user need to know and user need a way to change the password.

3. kimchi will set a initial random password for VM when create it.

And we should provide UI for user to change the password.

4. PUT(update) method can set a password for a VM created by other tool. but if expire is set for this VM, kimchi will not change the password. or kimchi can change the password but not change the expire.

Add UI to change VNC password and let user to control it.

5. when GET method to retrieve the password, if the VM is create by other-tools. And expire is set, kimchi raise http 400 error when timeout.

Kimchi should never automatically change the password if kimchi identified that password is set manually, why 'expire' matters here?

6. pass the ticket to vnc/spice websocket in cookie, not in URL. vnc/spice login page get the ticket from cookie.