On 07/30/2011 09:41 AM, Phil Steitz wrote:
> On 7/29/11 10:30 PM, Manoj Khangaonkar wrote:
>> On Fri, Jul 29, 2011 at 2:17 PM, gcollins <[email protected]> wrote:
>>> Hello Manoj,
>>>
>>> Thank you very much for the response.
>>>
>>> To make sure I understand, rephrasing my problem to match your example:
>>>
>>> File:*:File1.doc
>>> File:r,w:File2.doc
>>> ...... and so on
>>>
>>> Check permission:
>>> Subject.hasPermission("File:r:File1.doc") ;
>>>
>>> My problem is that I may have File1 to File500000, yet the user only has
>>> access permissions:
>>>
>>> File:*:File10.doc
>>> File:*:File1561.doc
>>> File:*:File496713.doc
>>>
>>> I don't want to check through File1 to File500000 to find out which ones
>>> should immediately be displayed to the user. If I understand you correctly,
>>> if I want to avoid this onerous check, it would be outside the scope of what
>>> Shiro is trying to achieve. i.e. it doesn't make sense for Shiro to have a
>>> method:
>>>
>>> Collection<String> permissions = Subject.getPermissions("File:r:*");
>>>
>>> to return me the list of files that the user can access.
>>>
>>> My understanding is correct?
>>>
>> Yes. Such a method currently does not exist.
>>
>> Whether Shiro should provide such a method is broader discussion. I'll
>> let Les & others comment on that.
>>
>> I can see such methods being useful. But at best, Shiro might be able
>> to add some search methods to the
>> Realm interfaces, but Realm implementor will still need to implement them.
> To some extent, these methods already exist in the Realm
> interfaces. Every realm must implement doGetAuthorizationInfo.
This actually isn't quite true. While Realms that extend the
AuthorizingRealm implement this method, it's not actually a part of the
Realm interface. This becomes even more apparent in trunk where Realm
doesn't implement Authorizer anymore.
> The
> returned AuthorizationInfo instance exposes permissions and roles.
> I am too new to Shiro to comment on the right separation of concerns
> here, but to solve the practical problem, you can just reuse the
> implementation of this method in whatever Realm you are using.
>
I would say that while Shiro covers "who are you" and, "can you access
X", the question that you are attempting to answer is "What resources
should I cache for you?" These really seem to be somewhat orthogonal
questions. While right now part of the answer to the second one is,
"all of the resources that I have access to", as an application grows
this is something that could change. I once spent a good amount of time
and effort trying to get my auth framework to support dynamic menu
building, which I think is very similar to what you're trying to do. I
believe I was using Acegi at the time, but after writing multitudes of
convoluted logic to convert and filter permissions based on
ever-changing business requirments, I reached the conclusion that I was
approaching this the wrong way. My recommendation would be to setup
something similar to the following:
interface UserDao {
Collection<URL> getAssignedResources(String user)
}
class MyRealm extends AuthorizingRealm {
UserDao userDao;
....
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals) {
AuthorizationInfo info = new AuthorizationInfo();
for(URL resources:
userDao.getAssignedResources(principals.getPrimaryPrincipal())) {
info.addStringPermission("resource:" + resources.toString());
}
return info;
}
class ResourceCacher {
UserDao userDao;
public void cacheResources(String user) {
for(URL resource: userDao.getAssignedResources(user)) {
cacheResource(resource);
}
}
}
This way, you have your domain-specific information (user-assigned
resources) in one place, and the authorization service uses it and the
caching service uses it, rather than trying to hijack the authorization
service to build up your caching logic. You would still use Shiro to
_protect_ your resources - say in case the user attempted to type in a
URL for another resource or something of that nature, but trying to use
the authorization service to build up caches (or menus) tends to make
your application less flexible than is often required in a world of
changing requirements.
> Phil
>>
>>> thanks in advance,
>>> Gareth
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/Retrieving-The-List-Of-Permissions-Or-Roles-For-A-User-tp6634613p6635017.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
