DomainPermission question

[Phil Steitz <ph...@gmail.com>]

I am trying to implement fine-grained auth using Shiro in a Google
App Engine app storing permissions using JDO.  It looks like
subclassing DomainPermission is the way to go.  I want to exploit
the wildcard setup (thanks for that!), but I am having a hard time
understanding how the constructors and setParts methods in
DomainPermission are going to interact with my persistent data. 
Specifically, neither the constructors that take actions and/or
targets as arguments nor the setParts method call setters for the
domain, action or targets properties of the class.  Similarly, the
default setter implementations don't call setParts.  I was assuming
that the way to extend this (per comment in the javadoc) was to
override the property getters and setters to interact with the
backing store.  But that doesn't look like it will work without also
overriding the constructors and setParts.  Is that the intent?  Is
there an example somewhere using JDBC or any other persistence store?

Sorry if this is a question for the user list, but since it is about
the Shiro sources, I thought I would ask here.  Could well be I am
misunderstanding the setup as I am pretty new to Shiro.  Thanks in
advance for patience.

Phil

Re: DomainPermission question

[Phil Steitz <ph...@gmail.com>]

On 6/22/11 12:40 PM, Les Hazlewood wrote:
> Hi Phil,
>
> Yep, you're right - the problems you're seeing are definitely bugs.
> Can you please open a Jira issue for this?

Will do, and once I get it working and have a better idea what I am
doing, I will add a patch.
> As for 'DomainPermission' - it was added a while ago (1.0) without
> much support added for it (i.e. there is no 'DomainPermissionResolver'
> or anything like that).  I think it was a class that slipped in to the
> API without being vetted much.

Nothing like "code that can be improved" to get people involved. 
Worked on me - he he.
> Anyway, that class exists because I was toying around with it as a
> concept based on permission classes I had used in my own projects that
> stored these things in a data store.  So it is rooted in real-world
> apps, but the current incarnation isn't ready (obviously, given the
> bugs that you've found).
>
> What it is good for at the moment (at least until the bugs are fixed)
> is more of an example of how you might construct your own Permission
> class.

That's what I am trying to do.  I'll open a JIRA and add comments to
the ticket. 

Thanks!

Phil
> Finally, in my own projects, I've renamed this to be a
> 'ResourcePermission', since the name 'domain' is a little abstract -
> most permissions reflect protecting resources (books, files,
> documents, users, etc) rather than a 'domain' (whatever that may
> mean).
>
> HTH,
>

Re: DomainPermission question

[Les Hazlewood <lh...@apache.org>]

Hi Phil,

Yep, you're right - the problems you're seeing are definitely bugs.
Can you please open a Jira issue for this?

As for 'DomainPermission' - it was added a while ago (1.0) without
much support added for it (i.e. there is no 'DomainPermissionResolver'
or anything like that).  I think it was a class that slipped in to the
API without being vetted much.

Anyway, that class exists because I was toying around with it as a
concept based on permission classes I had used in my own projects that
stored these things in a data store.  So it is rooted in real-world
apps, but the current incarnation isn't ready (obviously, given the
bugs that you've found).

What it is good for at the moment (at least until the bugs are fixed)
is more of an example of how you might construct your own Permission
class.

Finally, in my own projects, I've renamed this to be a
'ResourcePermission', since the name 'domain' is a little abstract -
most permissions reflect protecting resources (books, files,
documents, users, etc) rather than a 'domain' (whatever that may
mean).

HTH,

-- 
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com

On Tue, Jun 21, 2011 at 10:11 PM, Phil Steitz <ph...@gmail.com> wrote:
> I am trying to implement fine-grained auth using Shiro in a Google
> App Engine app storing permissions using JDO.  It looks like
> subclassing DomainPermission is the way to go.  I want to exploit
> the wildcard setup (thanks for that!), but I am having a hard time
> understanding how the constructors and setParts methods in
> DomainPermission are going to interact with my persistent data.
> Specifically, neither the constructors that take actions and/or
> targets as arguments nor the setParts method call setters for the
> domain, action or targets properties of the class.  Similarly, the
> default setter implementations don't call setParts.  I was assuming
> that the way to extend this (per comment in the javadoc) was to
> override the property getters and setters to interact with the
> backing store.  But that doesn't look like it will work without also
> overriding the constructors and setParts.  Is that the intent?  Is
> there an example somewhere using JDBC or any other persistence store?
>
> Sorry if this is a question for the user list, but since it is about
> the Shiro sources, I thought I would ask here.  Could well be I am
> misunderstanding the setup as I am pretty new to Shiro.  Thanks in
> advance for patience.
>
> Phil