Hi Manu,
> 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. > +1. We can derive the permission of a web page (URL) from the resource/s that are associated with/shown in that page. Until we encounter a situation where we cannot derive permission of the URL (any examples?), let's use existing permissions. Thanks On Thu, Jul 14, 2016 at 8:18 PM, Manuranga Perera <m...@wso2.com> wrote: > 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 : m...@wso2.com > -- Sajith Janaprasad Ariyarathna Software Engineer; WSO2, Inc.; http://wso2.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
