Daniel and Pat,
On Tue, Oct 14, 2008 at 11:16 AM, Lauk Daniel <
[hidden email]> wrote:
> Hello, Pat.
>
> I would suggest you rethink your navigation concept:
> Instead of basing the navigation on the roles, base it on the
> functionality and restrict the functionality according to the roles.
Daniel surfaces excellent points. Permissions were created for this
very purpose. If/Else logic based on roles can become extremely
cumbersome, even when the application only has 2 or 3 roles, as Daniel
pointed out. The combinations get quite messy very quickly. I'll
elaborate for Pat:
Roles are a coarse-grained concept and are only an _implicit_
indication of who can do what, based on what you define arbitrarily in
code. For example,
if ( subject.hasRole("Administrator") ) {
//show the "manage users" link.
}
This is just an arbitrary definition just because of the nature of
your application's business logic or requirements.
But what does this code really say? What are we trying to enforce?
We are trying to say "if the current user has the ability (permission)
to manage users, show them the link". That is an explicit statement
that can better be reflected by permissions. Consider this example:
if ( subject.hasPermission( "user:update" ) ) {
//show the "manage users" link.
}
Permissions describe raw functionality at the most basic level. They
describe the 'what' the user can do in the application rather than
arbitrary code blocks attributed to roles.
You then assign 'what' a person can do by assigning one or more
permissions to any role. Then you assign roles to users. Your
JSecurity Realm checks for the permissions across all of a user's
assigned roles.
So, you would considerably clean up your if/else permutations if you
used a permission check instead of role checks. This is because the
"Administrator" and "Supervisor" roles would probably both be assigned
the "user:update" permission, so you'd only have one permission check,
instead of many permutations.
Another side benefit of Permissions is that their definitions change
only when the application's raw functionality changes - this allows
you to create/delete/assign roles at runtime (if your business sees
that as desirable) instead of hard-coding role names in code. That
is, it is much 'safer' to hard-code permission checks rather than role
checks.
Cheers,
Les
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Locked
