<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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...<br>
    <br>
    <b>1.2 time frame</b><br>
    One person's excessively long timeout is another's excessively short
    timeout. <br>
    For 1.2 I suggest we move both the timeout and the refresh interval
    to a config file.<br>
    This would allow the user to effectively disable the refresh
    interval by setting it to <br>
    longer than the timeout. To make that flow workable, we'll need to
    ensure that all <br>
    ui actions force a refresh so the UI so that the system might be
    somewhat usable <br>
    in the case that the user set refresh to be greater than session
    timeout.<br>
    <br>
    <b>Long run</b><br>
    Approaches<br>
    &nbsp;1. Separate the credential validity period from the session
    timeout. This would <br>
    allow us to re-authenticate at one interval, while handling session
    timeout on <br>
    a different interval. <br>
    <br>
    2. Your option 3 below<br>
    <br>
    3. Implement a UI element that warns you when yuor session is about
    to timeout, then automatically <br>
    log them out of they don't respond.<br>
    <br>
    4. Some other alternatives I haven't thought of yet<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/25/2014 8:18 AM, Sheldon wrote:<br>
    </div>
    <blockquote cite="mid:530C9813.2090206@linux.vnet.ibm.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      I'd like to talk about timeout for sessions again. <br>
      Firstly, the default timeout of sessions is 60 minutes.&nbsp; It seems
      too long. <br>
      So I want to set the timeout of sessions explicitly.&nbsp; maybe 10
      minutes is OK.<br>
      If session got inactive for 10 minutes then it should expire
      automatically. <br>
      And should ask user for relogin. This is required for the security
      reason. <br>
      <br>
      But this timeout will not take effect on guest tab and host tabs.<br>
      <br>
      For guest tab, the root cause is because the front end refresh the
      vm list every 5 seconds <br>
      by sending the "GET /vms" REST API call to the server. <br>
      For host tabs. the front end will also get the host info and stats
      all the time.<br>
      <br>
      So the session will never timeout.<br>
      <br>
      There are several proposal for this problem.<br>
      1. UI set a timeout time. <br>
      if no users operations for a certain time(such as 5 seconds), UI
      stops to get vms or host info and stats.<br>
      and let&nbsp; server close session when timeout.<br>
      <br>
      2. UI log out automatically.<br>
      if no user operations for ertain time(such as 5 seconds), UI log
      out automatically.<br>
      <br>
      3. distinguish the user and JS requests.<br>
      Maybe there need an extra header to tell the requests from the JS
      request or the USER. <br>
      We should set the User-Agent of JS requests explicitly.<br>
      such as: <br>
      User-Agent: auto-robot/1.0<br>
      <br>
      I can check whether cherrypy has some user-agent filter for
      timeout. <br>
      even without this filter, I can set a extra data for Cherrpy
      Session. <br>
      and <span class="st"> can force the session to expire with&nbsp;<em>sessions</em>.<em>expire</em>().</span><br>
      <br>
      or a cookie to tell the sever this is request is send by JS robot.
      the similar method to User-Agent<br>
      <br>
      <br>
      Now the dispute is that:<br>
      1. When user is at Guests Tab, he wants to keep monitoring VM
      status, and he doesn't want session to be timed out. <br>
      2. the UI may collection host info and store host info. <br>
      If these two case, that means the /host and /vms URL can not need
      authentication.<br>
      <br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Thanks and best regards!

Sheldon Feng(&#20911;&#23569;&#21512;)<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:shaohef@linux.vnet.ibm.com">&lt;shaohef@linux.vnet.ibm.com&gt;</a>
IBM Linux Technology Center</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Adam King <a class="moz-txt-link-rfc2396E" href="mailto:rak@linux.vnet.ibm.com">&lt;rak@linux.vnet.ibm.com&gt;</a>
IBM C&amp;SI</pre>
  </body>
</html>