Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
- Subject: Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
- From: David Holt <email@hidden>
- Date: Thu, 19 Mar 2009 09:45:29 -0700
On 7-Mar-09, at 3:58 PM, Kieran Kelleher wrote:
I have been using Role Based access control mixed with Privileges
(on/off canViewThis, canEditThat, etc.), but I always get the
feeling there is better ways to do this security stuff .......
anyone care to share their user security strategies in terms of
access to pages, parts of pages and objects in WebObjects apps?
Hi Kieran,
I am implementing a system that assigns a user to a role and then
each role is given a specific set of navigation tabs for the pages
that they can see. This is all easily done using the
ERXNavigationMenu from ProjectWonder. I then customize a given page
where necessary (for example read only v.s. editable) for a given
role and point to it from that role's navigation menu.
This works really well for a small number of roles. You just create
as many variations of a given page as you need for the corresponding
roles.
Where this approach breaks down is when you start to have too many
roles and/or you are customizing too many pages to correspond to the
roles. I think at that point you'd want to create one page level
component and set privileges at the field level (as read only or
editable or invisible) depending on the privilege assigned to the role.
As always, I think a lot depends on the complexity of your
application. And I am not sure what the rule of thumb would be for
moving from one way to the other.
Do your access control strategies contemplate setting access right
down to the attribute level on a page?
David
On Mar 7, 2009, at 12:48 PM, Mike Schrag wrote:
well, wherever ... awake possibly, or whenever your auth code runs
to check for ACL's at the top of each request.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden