Hi all, AFAIK user-core already has a permission cache. So implementing another cache on session will be a just unnecessary optimization. Only performance issue will be the OSGi call to check the permission. I don't think that'll be a huge issue since it's a in-JVM call. My only concern is will there be any scenarios (clustered environment) where we'll web apps in a separate carbon server without backend components?
Thanks, Harshan Liyanage Senior Software Engineer WSO2 On Sep 8, 2016 10:12 AM, "Udara Rathnayake" <[email protected]> wrote: > > > On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera <[email protected]> wrote: > >> Hi All, >> >> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery >> based implementation) we are trying to standardize the permission check for >> UI bits. We need to check permissions for “pages” level as well as granular >> to the “units” level. For example; show/hide a button based on UI >> permission. Also should notice that these permissions are not unique to the >> front-end, thus can be directly mapped into the respective back-end osgi >> services. For example; device enroll permission will be checked on the >> enrollment page(front-end), as well as the inside the respective enrollment >> osgi service(back-end). >> >> And also there’s a requirement that any third-party application should be >> able to write their own UI based on our web apis. Hence we are expecting to >> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly >> call admin-service. >> >> [image: Inline image 1] >> >> >> >> As per the diagram, when a EMM web app receives a page render request >> from the browser, UUF will execute the the method isAuthorized() at the >> back-end JavaScript layer. JavaScript will include the “carbon” jaggery >> module which will import the RealmService OSGi service. Using RealmService >> we can invoke the Authorizer.isRoleAuthorized(). >> >> Whenever, third-party application requests for a permission check via >> EMM-API(JAX-RS), final result should be given invoking same >> Authorizer.isRoleAuthorized() method. >> >> One concern on this design was how to improve the *performance* of OSGi >> calls per permission check. One such suggestion is to retrieve all >> permissions for the current user and persist it on the “session”. IMO this >> would results some unforeseen issues and permission update on the backend >> will not immediately applied on the already logged users(eg. longer session >> timeouts). For example: users will still see the action buttons when >> clicked on it, it will return permission error. On the other hand, managing >> caching coherency is an extra effort for this approach. My suggestion is to >> utilize the permission check cache(if exists) at the user-core level which >> would be consistent across the platform. >> >> WDYT? >> >> @DS/UUF Team: I hope we need the similar permission check feature with >> the {{permission}} handlebar helper. >> > Isn't this similar to what we are trying to solve with secured helper > with permission? > > >> >> -- >> With Regards, >> >> *Rasika Perera* >> Software Engineer >> LinkedIn: http://lk.linkedin.com/in/rasika90 >> >> [image: wso2-signature-general.png] <https://wso2.com/signature> >> >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Regards, > UdaraR > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
