<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">It's authorization that I am talking
      about, please ignore this one and I will send another e-mail.
      Sorry for the inconvenience.<br>
      <br>
      Regards<br>
      <br>
      Wang Wen<br>
      &nbsp;<br>
      On 7/7/2014 4:40 PM, Wen Wang wrote:<br>
    </div>
    <blockquote cite="mid:53BA5CFD.9090900@linux.vnet.ibm.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Hi all,<br>
      <br>
      Due to the fact that Kimchi needs authentication feature to be
      designed. I an posting my point of view below of how I thought
      about doing it, including how I plan doing it in the front-end and
      request for help for the back end support.<br>
      <br>
      Kimchi changed to a traditional login patten in last release that
      makes Kimchi more secure to use. It Before login, the front-end
      can hardly get any html information before user actually login. As
      we discussed, root user will have full access to Kimchi whereas
      the non-root user will have restricted privileges. It will be
      easier and more decent to show the proper tabs to certain users
      that distinguished by the back-end. Now the tabs are generated by
      an xml file generated from the back-end that show all 5 tabs. We
      probably need to have the '<b>Host</b>' and '<b>template</b>' tab<u>
        removed</u> for non-root users, which is recommended to be done
      in the back-end.<br>
      <br>
      Also there need to be information provided to the front-end like
      the user-name, user-role as well as user-group, etc. that indicate
      user identity after login. The browser need the information to
      give certain privileges to certain users and disable the
      unnecessary functions. My suggestion is to have these 3 parameters
      passed:&nbsp;<b><small> </small></b><b>user-name, user-role</b> as
      well as <b>user-group</b>. There is a better extendibility to
      user the user-role other than isRoot so that we can define more
      roles in the future. As fact that we have only defined two roles
      now, the user-role parameter can be divided into root and guest
      based on user is root or non-root. These message can get from <b>sessiondada</b>,
      <b>cookie </b>or passed according to a query. the way passing the
      info of the user is still under discussion. Request for your
      advises. <br>
      <br>
      Best Regards<br>
      <br>
      Wang Wen<br>
      <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>
  </body>
</html>