• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Chuck Hill <email@hidden>
  • Date: Thu, 19 Mar 2009 15:32:53 -0700


On Mar 19, 2009, at 3:03 PM, David Holt wrote:


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!

Yeah, I annoy lots of people like that! :-P


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?

That is certainly possible, it really depends on the business domain. Often I find that some users will have a single role and some will have multiple roles. Thing of McDonalds. People working the tills might have the Counter Staff role. People doing the cooking might have the Grill Man role. A Manager might then have the Counter Staff and Grill Man role in addition to their specific Manager role.



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?

I think that you would have to have Magazine specific roles for that e.g. Publisher (Cooking for Techs), Writer (Marine Biology Monthly). You could have "template" roles that get copied and modified for each Magazine.




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?

http://www.niueisland.com/

Chuck

--
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
  • Follow-Ups:
    • Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
      • From: Johan Henselmans <email@hidden>
References: 
 >Digging up a Session object from an EOGenericRecord (From: Riccardo De Menna <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Riccardo De Menna <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Mike Schrag <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Riccardo De Menna <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Mike Schrag <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Riccardo De Menna <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Mike Schrag <email@hidden>)
 >Re: Digging up a Session object from an EOGenericRecord (From: Kieran Kelleher <email@hidden>)
 >Re: Access Control [was: Digging up a Session object from an EOGenericRecord] (From: David Holt <email@hidden>)
 >Re: Access Control [was: Digging up a Session object from an EOGenericRecord] (From: Chuck Hill <email@hidden>)
 >Re: Access Control [was: Digging up a Session object from an EOGenericRecord] (From: David Holt <email@hidden>)

  • Prev by Date: Re: Testing diffirent versions of IE on the same machine
  • Next by Date: Re: WOLips Can't update with Eclipse 3.4.2. Was: Eclipse+wolips nightly update failed
  • Previous by thread: Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
  • Next by thread: Re: Access Control [was: Digging up a Session object from an EOGenericRecord]
  • Index(es):
    • Date
    • Thread