On Mon, Jan 26, 2009 at 2:25 PM, Daniel J. Lauk <[email protected]>wrote:
> >> Well, actually, nobody but the assigned reviewer is allowed.
> >> As I will have the field around for DB queries anyway, I guess that
> >> permissions don't add value from the app logic point of view.
> >
> > Well, that depends on your app logic ;)
>
> Point taken. :-)
> Actually, I don't mind to have this logic around. The one thing I
> dislike though, is that I have to duplicate the code into the view of
> my web application to hide unavailable functionality from the UI. I
> hoped that with permissions it could turn out to a *simple* check.
You can still do this of course so you don't have to duplicate UI code - it
is just a trade-off. More rather than less permissions mean a little extra
processing time. But, if you don't assign hundreds per user or role, then
it won't really matter for most applications. The performance 'hit' will be
negligible for most applications, especially if you use 2nd-level caching to
minimize or eliminate RDBMS round trips.
> > In permission-based systems, Permissions describe raw application
> > functionality - they are the 'what' can be done in an application and
> have
> > no concept of 'who' can do something.
>
> Thanks for clarifying. I think I got that now. I'm only a little
> clumsy at using it. Although -- coming from the grails plugin -- I
> have to say that Peter's talk (w/ slides) made it a lot easier.
One thing that Peter (rightfully) tries to clarify as well is the difference
between a permission assignment and a permission check. Both situations use
a permission instance, so that overlap sometimes confuses people.
Assignment:
//allows the administrator role to 'edit' _any_ 'user':
adminstratorRole.addPermission( "user:edit" );
Check:
long idOfUserToEdit = //get the user ID being edited - perhaps as a query
parameter
//now construct the permission instance to use during the check:
String editSpecificUser = "user:edit:" + idOfUserToEdit;
if ( currentSubject.hasPermission( editSpecificUser ) ) {
//show the edit button
} else {
//don't show them the edit button? Gray it out?
}
Notice how the permission being checked is similar to the permission that
was originally assigned. That is because Permissions don't work as a simple
equality check, there is _implication_ logic that occurs: "user:edit"
permission (assigned) 'implies' the "user:edit:1234" permission (checked).
This does make permissions sometimes harder to understand, but once you get
the concept of implication down, you can really harness their power.
Thanks for the explanation and patience :-)
My pleasure :)
Cheers,
Les
