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 >
