On 7/30/11 10:45 AM, Jared Bunting wrote:
> 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.
Yeah, right, I should have said every authorizing realm, which I
assumed was being used here.
Phil
>
>> 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.
>>>>
>
