hasPermission(...) is better than hasRole(...), but the reason we are
moving towards the component mapping approach is that hasPermission(...)
could end up returning something anomalous if your business logic gets
complicated (which is where we lie). If it is as simple as ( some
activity == true ) then hasPermission(...) works, but if the internal
business logic gets expanded past role based access to include, for
example system configuration (or even whether the user has paid for a
particular feature), hasPermission(someActivity) may end up returning
false, even if they DO have that activity.
Not to mention again, by assigning activities to each of the components
involved, you've exposed your authentication system to the rest of the
application, which makes it harder to replace / swap.
Corporate restrictions prevents me from posting any real code, but
something like
<mx:Button id="deleteItem"
enabled="{UserModel.getUser(userKey).hasAccess(ItemTasks.DELETE)}" />
In User.as
public function hasAccess( task : String ) {
if ( _activities.include( _taskMapping[ task ] ) &&
configuration.taskAllowed( task ) ) {
return true;
}
return false;
}
P.S. Ignore some of the more funky quirks in my code... There are a few
hangovers there. And I do believe we are mainly arguing semantics at
this point ;)
Gk.
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
<blocked::http://www.inps.co.uk/>
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact [email protected]
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Yves Riel
Sent: 20 January 2009 17:34
To: [email protected]
Subject: RE: [flexcoders] Re: Roles Based UI
In our case, we use a similar scheme except that we have roles and
permissions. It is the permission that defines the access to the
component. If the user, in his role, has the permission set to true,
then the user gain access to the component. It is very flexible as you
can create many roles will similar or different permissions. At the end,
you do not tie up the UI to a specific role but to a permission.
E.g.
<mx:Button id="btndelete1" enabled="User.hasPermission('CanDelete')" />
<mx:Button id="btndelete2" enabled="User.hasPermission('CanDelete')" />
<mx:Button id="btnAdd" enabled="User.hasPermission('CanAdd')" />
etc...
You can see here that two buttons can be displayed using the same
permission.
________________________________
