You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Jared Bunting <ja...@peachjean.com> on 2012/07/11 21:31:28 UTC
SimpleAccountRealm implementing RolePermissionResolver
I just wanted to get a quick sentiment on this:
https://issues.apache.org/jira/browse/SHIRO-371
It seems useful to me (and was prompted by a question on Stack Overflow)
but it does add a public interface to a fairly central piece of the core
library. Are there any objections?
Thanks,
Jared
Re: SimpleAccountRealm implementing RolePermissionResolver
Posted by Jared Bunting <ja...@peachjean.com>.
But would that return the ini logic as a RolePermissionResolver, or
would it just return whatever RolePermissionResolver was set on the
IniRealm. To me, it would be confusing if it didn't return whatever
RolePermissionResolver was set on the IniRealm.
On the other hand, what I'm really after here is a
"IniRolePermissionResolver". My thought of making the realm implement
it was really juts because all of the logic is already there. However,
maybe pulling that logic out and providing a standalone
IniRolePermissionResolver would be better?
For reference, this is the question that prompted me to think about
this:
http://stackoverflow.com/questions/10692285/i-am-using-apache-shiro-under-camel-and-i-cannot-map-groups-to-roles-with-ldap-a/10694046#10694046
. I have also run into similar issues with ldap - the groups are mapped
to roles, but the application requires permissions, and the
role->permission needs to happen at the application level. The ini
seems like the simplest way to do this mapping.
Thanks,
Jared
On 07/12/2012 09:39 AM, Les Hazlewood wrote:
> Per Kalle's comments in the issue, it does sound a bit weird to do this.
>
> However, I could see how this could be used, i.e. OO Delegation (call
> the IniRealm, it delegates to its internal resolver).
>
> I wonder if there might be a better way? Because it is not common for
> Realms to implement this interface directly (and instead delegate to a
> resolver component), it feels like an 'implementation detail' to do
> this. That is, the end-user has to know that the Realm implements
> this interface when it is quite common that Realms do not do this.
>
> Maybe it can be a bit more explicit and conform to the behavior of any
> AuthorizingRealm? For example:
>
> myRealm.rolePermissionResolver = $iniRealm.rolePermissionResolver
>
> I'm not sure if this is better - it's just an idea for discussion.
>
> Thoughts?
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
>
>
> On Wed, Jul 11, 2012 at 12:31 PM, Jared Bunting
> <ja...@peachjean.com> wrote:
>> I just wanted to get a quick sentiment on this:
>>
>> https://issues.apache.org/jira/browse/SHIRO-371
>>
>> It seems useful to me (and was prompted by a question on Stack Overflow)
>> but it does add a public interface to a fairly central piece of the core
>> library. Are there any objections?
>>
>> Thanks,
>> Jared
Re: SimpleAccountRealm implementing RolePermissionResolver
Posted by Kalle Korhonen <ka...@gmail.com>.
Looks better to me, not difficult to understand. It'd increase
symmetry if we were to add a getPermissionResolver() to
PermissionResolverAware interface.
Kalle
On Thu, Jul 12, 2012 at 7:39 AM, Les Hazlewood <lh...@apache.org> wrote:
> Per Kalle's comments in the issue, it does sound a bit weird to do this.
>
> However, I could see how this could be used, i.e. OO Delegation (call
> the IniRealm, it delegates to its internal resolver).
>
> I wonder if there might be a better way? Because it is not common for
> Realms to implement this interface directly (and instead delegate to a
> resolver component), it feels like an 'implementation detail' to do
> this. That is, the end-user has to know that the Realm implements
> this interface when it is quite common that Realms do not do this.
>
> Maybe it can be a bit more explicit and conform to the behavior of any
> AuthorizingRealm? For example:
>
> myRealm.rolePermissionResolver = $iniRealm.rolePermissionResolver
>
> I'm not sure if this is better - it's just an idea for discussion.
>
> Thoughts?
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
>
>
> On Wed, Jul 11, 2012 at 12:31 PM, Jared Bunting
> <ja...@peachjean.com> wrote:
>> I just wanted to get a quick sentiment on this:
>>
>> https://issues.apache.org/jira/browse/SHIRO-371
>>
>> It seems useful to me (and was prompted by a question on Stack Overflow)
>> but it does add a public interface to a fairly central piece of the core
>> library. Are there any objections?
>>
>> Thanks,
>> Jared
Re: SimpleAccountRealm implementing RolePermissionResolver
Posted by Les Hazlewood <lh...@apache.org>.
Per Kalle's comments in the issue, it does sound a bit weird to do this.
However, I could see how this could be used, i.e. OO Delegation (call
the IniRealm, it delegates to its internal resolver).
I wonder if there might be a better way? Because it is not common for
Realms to implement this interface directly (and instead delegate to a
resolver component), it feels like an 'implementation detail' to do
this. That is, the end-user has to know that the Realm implements
this interface when it is quite common that Realms do not do this.
Maybe it can be a bit more explicit and conform to the behavior of any
AuthorizingRealm? For example:
myRealm.rolePermissionResolver = $iniRealm.rolePermissionResolver
I'm not sure if this is better - it's just an idea for discussion.
Thoughts?
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Wed, Jul 11, 2012 at 12:31 PM, Jared Bunting
<ja...@peachjean.com> wrote:
> I just wanted to get a quick sentiment on this:
>
> https://issues.apache.org/jira/browse/SHIRO-371
>
> It seems useful to me (and was prompted by a question on Stack Overflow)
> but it does add a public interface to a fairly central piece of the core
> library. Are there any objections?
>
> Thanks,
> Jared