I want to suggest we divide the discussion into the things we should consider for 1.2, and those we should consider in the future...

1.2 time frame
One person's excessively long timeout is another's excessively short timeout.
For 1.2 I suggest we move both the timeout and the refresh interval to a config file.
This would allow the user to effectively disable the refresh interval by setting it to
longer than the timeout. To make that flow workable, we'll need to ensure that all
ui actions force a refresh so the UI so that the system might be somewhat usable
in the case that the user set refresh to be greater than session timeout.

Long run
Approaches
1. Separate the credential validity period from the session timeout. This would
allow us to re-authenticate at one interval, while handling session timeout on
a different interval.

2. Your option 3 below

3. Implement a UI element that warns you when yuor session is about to timeout, then automatically
log them out of they don't respond.

4. Some other alternatives I haven't thought of yet

On 2/25/2014 8:18 AM, Sheldon wrote:

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@linux.vnet.ibm.com>
IBM Linux Technology Center
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-- 
Adam King <rak@linux.vnet.ibm.com>
IBM C&SI