Hi Harshan/Udara, Please find my inline comments.
Isn't this similar to what we are trying to solve with secured helper with > permission? Yes. Only difference is we don't use a helper for this since it doesn't add much value in this case. Instead we are setting a flag at the Backend JavaScript layer so templating layer can change rendering based on that flag. 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. +1. My only concern is will there be any scenarios (clustered environment) > where we'll web apps in a separate carbon server without backend components? > Currently login process is done through OSGi calls(via jaggery "carbon" module). UserCore OSGi services are available with carbon platform for any given carbon server. Hence, it won't be an issue. But we might need to share user store across nodes. Thanks, Rasika On Thu, Sep 8, 2016 at 10:34 AM, Harshan Liyanage <[email protected]> wrote: > 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 >> >> -- 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
