On 07/16/2014 09:53 AM, Aline Manera wrote:
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"} ... }
As we discussed today in the scrum meeting, we will keep the authorization map in the tabs.xml The frontend can not guarantee authorization, it must be done in backend, so even if a hacker change the JS to get the admin view, he/she will not be able to perform any operation (blocked by backend) The scrum meeting log can be found at http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-07-16-13.0...
On 2014年07月16日 03:44, alinefm@linux.vnet.ibm.com wrote:
From: Aline Manera <alinefm@linux.vnet.ibm.com>
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@linux.vnet.ibm.com> --- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel