Re: [Kimchi-devel] [PATCH 2/3] authorization: Add "access" elements to tabs.xml to describe user view

On 07/16/2014 04:38 AM, Royce Lv wrote: > This role and mode infomation is stored in tabs.xml, > If backend is using this information, I guess its difficult to update > operations a role can perform. The content in the xml is static, ie, it will not change. It only describe which view a user role (admin or user) will get in Kimchi > If we are using it in frontend, > is that mean user can hack .js to change the access mode? > I suppose roles and operations mappings need to be restored in backend > db to make sure APIs are protected by authorization? > ACK. But I don't think we need to store that info in a db as it is static. I will create a new API /authorization that returns the map presented in the xml. <tab>: {<role>: <mode>} Example: GET /authorization { "guests": {"admin": "admin", "user": "byInstance"}, "templates": {"admin": "admin", "user": "byInstance"} ... }

> On 2014年07月16日 03:44, alinefm(a)linux.vnet.ibm.com wrote: >> From: Aline Manera <alinefm(a)linux.vnet.ibm.com&gt; >> >> Kimchi has 2 user roles: "admin" with full control of Kimchi features >> and "user" with limited access >> To describe how each tab should be displayed to user, an "access" >> element was added to tabs.xml indicating which view mode each role has. >> >> <access role="..." mode="..."/> >> >> The "mode" attribute values are: >> >> - none: do not show the tab; >> - admin: full instance access; >> - read-only: read-only access; >> - byInstance: each resource will have its configuration sent by the >> backend ("access" parameter); >> >> The user will only be able to manage the guests he/she is assigned for, >> because that the guest tab has 'mode' == by-instance. >> That way each VM will have a new parameter "access" indicating if user >> has >> "full" or "read-only" access to this VM. >> >> As a user can edit a guest, he/she may need to know which networks >> and storage pools are configured, so set network and storage tab 'mode' >> to read-only. >> >> And as user should not perform any operation on host or templates, set >> their 'mode' attributes to 'none'. >> >> Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com&gt; >> --- >> config/ui/tabs.xml | 15 +++++++++++++++ >> plugins/sample/ui/config/tab-ext.xml | 3 +++ >> 2 files changed, 18 insertions(+) >> >> diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml >> index b045521..f79684c 100644 >> --- a/config/ui/tabs.xml >> +++ b/config/ui/tabs.xml >> @@ -1,22 +1,37 @@ >> <?xml version="1.0" encoding="utf-8"?> >> <tabs> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="none"/> >> + >> <title>Host</title> >> <path>tabs/host.html</path> >> </tab> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="byInstance"/> > Maybe more role for guests? Virtualization admin can create/destroy, > guest system admin can start and stop, guest user can just login and > logout. For 1.3 only those 2 roles will be added. And then we can add more and more according to our needs. >> + >> <title>Guests</title> >> <path>tabs/guests.html</path> >> </tab> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="none"/> > I suppose also read-only for 'user', because user may want to browser > templates available, check details of the template to make decision > about which to use. A user will no be able to create a VM. So why he/she needs to know details about a template as the only proposal of templates is creating VMs? Let me explain you the full idea: - For now (1.3) we only have 2 roles: admin and user - admin role can do everything in kimchi - user role only can manage the VMs assigned to him After getting it done, we idea is add more roles and levels for users. Example: - user role only can get the console of a VM he/she is assigned for - user role only can start/stop/console of VM ... and so on Because that, the mode for a user role in the guests tab is set to "byInstance" as each VM must tell what kind of access the user has to it >> + >> <title>Templates</title> >> <path>tabs/templates.html</path> >> </tab> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="read-only"/> >> + >> <title>Storage</title> >> <path>tabs/storage.html</path> >> </tab> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="read-only"/> >> + >> <title>Network</title> >> <path>tabs/network.html</path> >> </tab> >> diff --git a/plugins/sample/ui/config/tab-ext.xml >> b/plugins/sample/ui/config/tab-ext.xml >> index 8e0b3d3..a1fb1c2 100644 >> --- a/plugins/sample/ui/config/tab-ext.xml >> +++ b/plugins/sample/ui/config/tab-ext.xml >> @@ -1,6 +1,9 @@ >> <?xml version="1.0" encoding="utf-8"?> >> <tabs-ext> >> <tab> >> + <access role="admin" mode="admin"/> >> + <access role="user" mode="none"/> >> + >> <title>SampleTab</title> >> <path>plugins/sample/tab.html</path> >> </tab> > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel