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 15:03:28 -0700
On 19-Mar-09, at 11:31 AM, Chuck Hill wrote:
Hi David,
On Mar 19, 2009, at 9:45 AM, David Holt wrote:
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.
For how I do it, Roles are used to aggregate privileges and
specific privileges grant access to pages, menu items, etc.
Man, you always give me new twists to think about! But you're right,
a role would have a hard time specifying privileges, it is much
better to come at a Role as an aggregate of them.
Would this mean that a person can have multiple roles in the
application?
If they can, can you somehow limit their role to the context that
they're working in, in the application? For example, I run a
(parabolic - if you know what I mean ;-) web application that
publishes three webzines. On two of them I am a writer and on the
other the publisher, can I be assigned to a different role depending
on which webzine area I have navigated into?
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?
It would not be fun otherwise, would it?
Oh I'm having plenty of fun without digging this far down ;-)
Where is Goat Island, again?
David
Chuck
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:
email@hidden
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:
40global-village.net
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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