Following are few questions I have on C5 permission model. Answers may have already been discussed, and I might have missed. If so, shall we get them on mail.
Action namespaces We have namespaced the permission by the “protocol” of the resource URI. Then, do we need to namespace the actions as well? topoic:view, api:view, dashboard:view has almost the semantic. Having it just as “view” will be useful when we want to use the same code or same lifecycle xml to govern them. Because unlike resource URI, which are just arbitrary strings, semantic of these words are understood by the code/ lifecycle xml. Permissions for UI pages I think there is no need to introduce a separate permission namespace for UI (or use a very limited one). Actual customer is concerned about giving permission to a real resource (topic, API, proxy ...) not to a UI URL. Ideally, for each page, we associate the page with an existing permission space using a URI pattern mapping. Eg: Let’s assume http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has to be associated with {jms://petNews/catNews, jms.view } And for this we may introduce following UUF directive to the page In ./pages/topics/{+topicPath}.hbs file … {{secure “jms://{topicPath}” ”jms:view”}} <html> <h1>Info about the topic: {{topicPath}}<h2> … Getting paginated list of resources Following performance issue will occur when we try to obtain a paginated resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets assume we need to show first 10 store artifacts (eg: APIs) in UI / or through API. To archive this we get the first 10 resource, and then filter it by permission in Java by iterating each. Assume out of that 10, the user can only see 4, then we need to get next 10 and filter and next 10 … Now assume we need to show the last 10 resources in UI. This is even worse. In current GReg with LDAP this will take about 10min if we have 8000 resources regardless of the user (last time I checked). Hypothetically, if we have a JDBC user store and the resource are in the same DB, this is a single join query. Obviously, this will not work in a real world case since permission are in different place. Perhaps we can use Lucene indexing? But how do we invalidate the indexer cache? Criteria for using to Group vs Role Currently we have associated everything with a role, in C5 some should become groups and others should become groups. Eg: Currently in dashboard server, any given dashboard can be associated with any role via UI, and only that role (and admins) will be able to see it. In C5 should dashboard will have a permission {dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give the ability to associate it with a Role or Group? (I personally don’t see the point of having two concepts, but if we do, we should have a clear guideline when to use which) Code duplication due to un-polymorphic Group and Role Group class and the Role class share lot of method signatures but there is no common interface both implements. Therefore, devs may have to repeat code sections for each by copy-pasting, not using proper polymorphism. Eg: UI for adding users to a Role/Group cannot share same code. Maybe this kind of code is rare, is it? If so we can ignore this. -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
