Thanks a lot. Loving isis ! Sent from my iPad
> On Oct 18, 2013, at 7:56 AM, Dan Haywood <[email protected]> > wrote: > >> On 18 October 2013 07:50, james agada <[email protected]> wrote: >> >> Thanks. I suppose if we want these to apply to the RO viewer that we >> will need to use the wrapper. > > > No... the RO viewer is just a different sort of UI, so they will be applied > automatically. > > > Is there a code snippet example of the >> wrapper usage? Are there any gotchas? >> >> > so, not sure if this question now applies, but if so...look at the > integration testing page [4] I linked to, also [5] > > WrapperFactory is just another domain service that gets injected wherever > it's needed... register WrapperFactoryDefault in isis.properties > > [4] http://isis.apache.org/core/integtestsupport.html > [5] > https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/actions/ToDoItemTest_completed.java > > >> Sent from my iPhone >> >>> On Oct 18, 2013, at 7:22 AM, Dan Haywood <[email protected]> >> wrote: >>> >>>> On 17 October 2013 16:45, james agada <[email protected]> wrote: >>>> >>>> >>>> shiro.ini allows one to configure permissions on an object. How does >> isis >>>> use these configurations? >>> >>> >>> They are used to determine what to show and enable in the UI. >>> >>> For each class member (ie property, collection or action), Isis checks >> when >>> rendering the UI if that member is visible for the current user, and if >> so >>> whether it is enabled for them. >>> >>> More precisely, the check is whether the member is visible/enabled for >> any >>> role that the current user has. >>> >>> The format of the permissions is documented at [1], other material on >> Shiro >>> is listed at [2] >>> >>> >>> Are they automatically applied? >>> >>> yes. >>> >>> >>>> Is there an API >>>> or a service that we call? >>> >>> no ... this is done by Isis when painting the UI; there is no need for >> the >>> domain classes to do anything >>> >>> Do note that what this also means is that an object can programmatically >>> call any method on some other object and Isis won't know or care. In >> other >>> words, security is only applied for UI -> domain interactions, not domain >>> -> domain interactions. >>> >>> There is a way to get around this though; one can use the WrapperFactory >> to >>> wrap the called object... in which case Isis will apply security and >> other >>> checks [3][4]] >>> >>> >>> >>> >>>> If a user does not have read permission on an >>>> object or write permission on an object, what happens? >>> >>> see [1]; they won't be able to see any class members for that object >> (when >>> rendered in the UI). However, other domain objects can still interact >>> programmatically with the object. >>> >>> HTH >>> Dan >>> >>> [1] >>> >> http://isis.apache.org/components/security/shiro/format-of-permissions.html >>> [2] http://isis.apache.org/components/security/shiro/about.html >>> [3] http://isis.apache.org/core/wrapper.html >>> [4] http://isis.apache.org/core/integtestsupport.html >>
