[Kimchi-devel] [RFC] timeout for sessions

[Sheldon]

I'd like to talk about timeout for sessions again.
Firstly, the default timeout of sessions is 60 minutes.  It seems too long.
So I want to set the timeout of sessions explicitly.  maybe 10 minutes 
is OK.
If session got inactive for 10 minutes then it should expire automatically.
And should ask user for relogin. This is required for the security reason.

But this timeout will not take effect on guest tab and host tabs.

For guest tab, the root cause is because the front end refresh the vm 
list every 5 seconds
by sending the "GET /vms" REST API call to the server.
For host tabs. the front end will also get the host info and stats all 
the time.

So the session will never timeout.

There are several proposal for this problem.
1. UI set a timeout time.
if no users operations for a certain time(such as 5 seconds), UI stops 
to get vms or host info and stats.
and let  server close session when timeout.

2. UI log out automatically.
if no user operations for ertain time(such as 5 seconds), UI log out 
automatically.

3. distinguish the user and JS requests.
Maybe there need an extra header to tell the requests from the JS 
request or the USER.
We should set the User-Agent of JS requests explicitly.
such as:
User-Agent: auto-robot/1.0

I can check whether cherrypy has some user-agent filter for timeout.
even without this filter, I can set a extra data for Cherrpy Session.
and can force the session to expire with /sessions/./expire/().

or a cookie to tell the sever this is request is send by JS robot. the 
similar method to User-Agent


Now the dispute is that:
1. When user is at Guests Tab, he wants to keep monitoring VM status, 
and he doesn't want session to be timed out.
2. the UI may collection host info and store host info.
If these two case, that means the /host and /vms URL can not need 
authentication.


-- 
Thanks and best regards!

Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140225/cd3bb371/attachment.html>