Thread: [Rainbowportal-devel] Implementing row-level security for module data
Brought to you by:
danijel_kecman,
manudea
From: Mark M. <mar...@ar...> - 2003-04-29 06:00:48
|
Last night I started the process of implementing row-level access control for edit/delete privileges in the Discussion module. The basic goal I stated in a separate email yesterday, to allow users to edit/delete their own entries (if they don't have any children). Eventually I would like to extend this concept to other modules, e.g. anyone could add a new announcement, but you can only edit announcements that you have created. This approach seems to violate one of the underlying design decisions of IBS and Rainbow. In these existing system you can only set access permissions (add/edit/delete) for every row of module instance data (and these permissions can only be assigned to a limited set of groups: everyone, authenticated, non-authenticated, and admins, e.g. there is no way to set a permission to a custom role). As I started working on a strategy I discovered the existing inheritance model for Page and Add/Edit page which I will summarize here. Let me know if I got this correct. Rainbow.UI.EditItemPage.DiscussionEdit->LoadSettings {where I could do my permission checks ?} Rainbow.UI.EditItemPage->LoadSettings {does a security check for Edit permissions} Rainbow.UI.Page->LoadSettings {currently does nothing} I can override LoadSettings() in the discussion DiscussionEdit page and do my own permission checks, but I have the following problems 1) if I call base.Load Settings(), EditItemPage.LoadSettings() does its more primitive 'group' check and denies access to the user 2) if I don't call base.Load Settings(), then I run the risk that sometime in the future a developer will add code to one of my parents LoadSettings() that will do something other than permission checks. If Load Settings is guaranteed to ALWAYS ONLY check permissions, I am happy to override it. If this is the case, I also suggest we rename this method to something like CheckAccessPermissions(). If LoadSettings could be used to load additional 'non-access settings' in the future, then we need another solution, perhaps still a CheckAccessPermissions() method called from LoadSettings, which can be overridden at any level. I hope this is a clear explanation :) Ideas? Mark |
From: Cory I. <cis...@ya...> - 2003-04-29 13:22:03
|
Mark, It sounds to me like you need the group implementation that Geert is proposing. At some point we will have to split security out so that is is as flexible as you need it. Right now I see implementations like you are looking for as customizations at the module level. Cory Mark McFarlane <mar...@ar...> wrote: Last night I started the process of implementing row-level access control for edit/delete privileges in the Discussion module. The basic goal I stated in a separate email yesterday, to allow users to edit/delete their own entries (if they don't have any children). Eventually I would like to extend this concept to other modules, e.g. anyone could add a new announcement, but you can only edit announcements that you have created. This approach seems to violate one of the underlying design decisions of IBS and Rainbow. In these existing system you can only set access permissions (add/edit/delete) for every row of module instance data (and these permissions can only be assigned to a limited set of groups: everyone, authenticated, non-authenticated, and admins, e.g. there is no way to set a permission to a custom role). As I started working on a strategy I discovered the existing inheritance model for Page and Add/Edit page which I will summarize here. Let me know if I got this correct. Rainbow.UI.EditItemPage.DiscussionEdit->LoadSettings {where I could do my permission checks ?} Rainbow.UI.EditItemPage->LoadSettings {does a security check for Edit permissions} Rainbow.UI.Page->LoadSettings {currently does nothing} I can override LoadSettings() in the discussion DiscussionEdit page and do my own permission checks, but I have the following problems 1) if I call base.Load Settings(), EditItemPage.LoadSettings() does its more primitive 'group' check and denies access to the user 2) if I don't call base.Load Settings(), then I run the risk that sometime in the future a developer will add code to one of my parents LoadSettings() that will do something other than permission checks. If Load Settings is guaranteed to ALWAYS ONLY check permissions, I am happy to override it. If this is the case, I also suggest we rename this method to something like CheckAccessPermissions(). If LoadSettings could be used to load additional 'non-access settings' in the future, then we need another solution, perhaps still a CheckAccessPermissions() method called from LoadSettings, which can be overridden at any level. I hope this is a clear explanation :) Ideas? Mark Cory Isakson Online Status: --------------------------------- 3.9 Cents/min. No Fees or Minimums! http://www.dial4life.com --------------------------------- --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. |