I'll give an example of why the existing behavior makes sense to me: user:read:jsmith:username
Just because I can read (view) the jsmith user's username does _not_ imply that I should be able to see all of jsmith's user data. Perhaps I shouldn't be able to see the user record's password field for example. Granted, this is just an example (and I'm not even advocating that you format permission strings in this way - I would probably arrange the tokens differently), but it is a fairly common one that illustrates why WildcardPermission tokens usually start out more general and get more specific as you go further down the permission string. The large majority of use cases of the WildcardPermission assume this type of behavior and this convention, so I don't know that it should be changed. But the beauty of the Permission interface is that you could change this default logic slightly to meet your application's needs by creating your own implementation, even using the WIldcardPermission's source code as the bases for your (slightly different) implementation. That's my .02 :) Les On Thu, Nov 11, 2010 at 7:15 AM, Philippe Laflamme <[email protected]>wrote: > > > Brian Demers wrote: > > > > However in your case your saying a more specific permission grants access > > to > > a more general permission. Maybe this is the part that I do not > > understand. > > > > Well that may depend on how Shiro behaves, but there's a subtlety here that > is important. > > What I'm trying to express is that a more specific permission implies all > lesser specific permissions "up" it's path. But the subtlety is that this > does not GRANT these permissions, it implies them. The end result is not > the > same as if I had explicitly stated that the user had the lesser specific > permission. > > An example will help. > > userA=thing:read:foo > userB=thing:read:foo:bar > > Current situation: > | User | Permission | Permitted | > | userA | thing:read:foo | true | > | userA | thing:read:foo:bar | true | > | userA | thing:read:foo:foobar | true | > | userB | thing:read:foo | false | > | userB | thing:read:foo:bar | true | > | userB | thing:read:foo:foobar | false | > > My situation: > | User | Permission | Permitted | > | userA | thing:read:foo | true | > | userA | thing:read:foo:bar | true | > | userA | thing:read:foo:foobar | true | > | userB | thing:read:foo | true | > | userB | thing:read:foo:bar | true | > | userB | thing:read:foo:foobar | false | > > In my situatiuon, eventhough both userA and userB have "true" for > permission > "thing:read:foo", they don't have the same permission of other more > specific > permissions (foobar). This is the difference with granting and implying a > permission. > > Imagine that we have TaskLists and Tasks inside them. My use-case is > granting access to a specific Task from my TaskList to a friend, but > without > exposing the whole TaskList to my friend. My friend needs to see my > TaskList > to access the Task I gave him access to... > > Does this clarify things? > > Cheers, > Philippe > > On Thu, Nov 11, 2010 at 9:34 AM, Philippe Laflamme > <[email protected]>wrote: > > > > > Hi, > > > > I've got a question regarding the current implementation of > > WildcardPermission. > > > > Currently, the following holds true: > > > > thing:read:foo implies thing:read:foo:bar > > > > Which basically means that if you can "read" the "foo" "thing", you can > > also > > "read" the "bar" "thing" in the "foo" "thing". > > > > But the reverse statement does not hold true: > > > > thing:read:foo:bar does NOT imply thing:read:foo > > > > Meaning that if you can read "bar" you can't read "foo". > > > > Now, at first I thought that it made sense, but after thinking about it, > I > > can't figure out what's a valid use case for this. > > > > My reasoning is based on the fact that "bar" in this situation is > > something > > that belongs to "foo" (otherwise, I would have a separate permission > > domain, > > ie: otherthing:read:bar). So if "bar" only exists if "foo" also does, > what > > is the valid use case of allowing access to "bar" but not to "foo"? > > > > Note that saying that the "longer" permission implies the "shorter" DOES > > NOT > > imply other longer permissions. That is, > > > > thing:read:foo:bar implies thing:read:foo --> true > > thing:read:foo:bar implies thing:read:foo:foobar --> false > > > > Is my reasoning valid? > > > > I've created my own Permission implementation that does exactly that and > > it > > behaves as expected (I can read foo, bar, but not foobar). I'm wondering > > what is a valid use-case for NOT wanting this behaviour? > > > > Thanks! > > Philippe > > -- > > View this message in context: > > > http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5728829.html > > Sent from the Shiro User mailing list archive at Nabble.com. > > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5729002.html > Sent from the Shiro User mailing list archive at Nabble.com. >
