You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by james agada <ok...@gmail.com> on 2013/10/17 17:45:30 UTC
Using Shiro
Forgive me if this has been asked before.
shiro.ini allows one to configure permissions on an object. How does isis
use these configurations? Are they automatically applied? Is there an API
or a service that we call? If a user does not have read permission on an
object or write permission on an object, what happens?
Re: Using Shiro
Posted by Okwui <ok...@gmail.com>.
Thanks a lot. Loving isis !
Sent from my iPad
> On Oct 18, 2013, at 7:56 AM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> On 18 October 2013 07:50, james agada <ok...@gmail.com> 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 <da...@haywood-associates.co.uk>
>> wrote:
>>>
>>>> On 17 October 2013 16:45, james agada <ok...@gmail.com> 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
>>
Re: Using Shiro
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 18 October 2013 07:50, james agada <ok...@gmail.com> 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 <da...@haywood-associates.co.uk>
> wrote:
> >
> >> On 17 October 2013 16:45, james agada <ok...@gmail.com> 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
>
Re: Using Shiro
Posted by james agada <ok...@gmail.com>.
Thanks. I suppose if we want these to apply to the RO viewer that we
will need to use the wrapper. Is there a code snippet example of the
wrapper usage? Are there any gotchas?
Sent from my iPhone
> On Oct 18, 2013, at 7:22 AM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> On 17 October 2013 16:45, james agada <ok...@gmail.com> 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
Re: Using Shiro
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 17 October 2013 16:45, james agada <ok...@gmail.com> 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