Permission Re-factoring Project
Locked
Permission Re-factoring Project
 
|
Now that the new service based permission framework is in place, it
would be nice to get a community effort going to help clean up some of the code & views to utilize this new infrastructure. I'm calling out to the community to see if there are any interested parties... The major basic tasks at hand are as follows: 1) change the use of the required-permissions element in service definitions to use the infrastructure (61 instances). 2) move the permission checking from the service code to the service definition 3) move the permission checking from template (FTL & BSH) files into the screen definition The first is the highest priority only because we want to remove the required-permissions element from the schema, this should no longer be used. However, if this is removed now, there will be 61 errors each time OFBiz starts up and I don't think is reasonable. Removing these, will also help display the 'best practices' of handling permissions. This should be a fairly easy task since they are simple permission checks. More advanced tasks include: 1) re-factoring specific permission checking code for content creation and modification 2) re-factoring specific permission checking code for party creation and modification ... orders, workefforts, etc. Before anyone jumps in on any of these, a group discussion would be in order. It seems that there may be certain areas where we have current permission checking which we may not want to continue. For example, it may not make sense to require permissions to create a workeffort, or a party; as long as the user has an account and is authenticated. These are topic for future discussion when the time comes. This is going to take quite a while to do, so we'll probably start with creating a top level JIRA issue as an overview of the entire 'project'. Then create sub-tasks for each specific iteration of re- factoring. This entire 'project' will be tracked through JIRA issue: https://issues.apache.org/jira/browse/OFBIZ-609 If anyone is specifically involved in extending or developing on top of any specific area, this is a good time to get involved with these changes as they will ultimately effect you down the road. I'm hoping to see a number of you get involved with this as it will ultimately effect workflows for vertical applications and extensions to OOTB OFBiz. Please feel free to comment and discuss, design decisions should be placed in JIRA as well. Sub tasks can be created with OFBIZ-609 and please feel free to do so. Andrew |
smime.p7s (3K)
Re: Permission Re-factoring Project
|
|
Re: Permission Re-factoring Project
|
|
Re: Permission Re-factoring Project
|
|
On Jan 10, 2007, at 12:26 PM, Adrian Crum wrote: > Comments inline: > > Andrew Zeneski wrote: >> The major basic tasks at hand are as follows: >> 1) change the use of the required-permissions element in service >> definitions to use the infrastructure (61 instances). >> 2) move the permission checking from the service code to the >> service definition >> 3) move the permission checking from template (FTL & BSH) files >> into the screen definition > > What about conditional code within the ftl files, which controls > the display of certain items - how will that be handled? In other > words, security permissions control what buttons are displayed/ > enabled - how will those be handled? and test for these fields in the FTL files. So, the screen definitions will handle all permission checks, and if the FTL files need to know (like view profile for example) then we'll set fields in the definition (canEditSecurity, canViewCreditCard) and then use these within the FTLs. > >> Before anyone jumps in on any of these, a group discussion would >> be in order. It seems that there may be certain areas where we >> have current permission checking which we may not want to >> continue. For example, it may not make sense to require >> permissions to create a workeffort, or a party; as long as the >> user has an account and is authenticated. These are topic for >> future discussion when the time comes. > > David made a good point yesterday about the possibility of > introducing code paths that could bypass security altogether. Has > that been resolved? > my proposal, but after looking at alternatives the same can be accomplished by explicitly re-routing security. Base operations may require a specific permission, exampleCreatePermission for instance. If you need a way to bypass this under certain conditions, then you create an ECA (commit) on exampleCreatePermission, if hasPermision == false, run a different permission service. Now your permissions are the base permission OR your custom permission. Much safer than an implicit bypass. Andrew |
Re: Permission Re-factoring Project
|
|
In reply to this post by cjhowe
I don't think it make sense to wait. I expect this will take quite a
while with many iterations. We definitely won't deprecate any existing code until everything is complete; and any new code should follow the new patterns. The schema changes for required-permissions would be nice to remove before the release however, but this is just my opinion. Andrew On Jan 10, 2007, at 12:20 PM, Chris Howe wrote: > Because of the size of the change, would it be wise > not to commit the changes until after the release? > (just questioning, not providing an opinion either > way) > > --- Andrew Zeneski <[hidden email]> wrote: > >> Now that the new service based permission framework >> is in place, it >> would be nice to get a community effort going to >> help clean up some >> of the code & views to utilize this new >> infrastructure. I'm calling >> out to the community to see if there are any >> interested parties... >> >> The major basic tasks at hand are as follows: >> 1) change the use of the required-permissions >> element in service >> definitions to use the infrastructure (61 >> instances). >> 2) move the permission checking from the service >> code to the service >> definition >> 3) move the permission checking from template (FTL & >> BSH) files into >> the screen definition >> >> The first is the highest priority only because we >> want to remove the >> required-permissions element from the schema, this >> should no longer >> be used. However, if this is removed now, there will >> be 61 errors >> each time OFBiz starts up and I don't think is >> reasonable. Removing >> these, will also help display the 'best practices' >> of handling >> permissions. This should be a fairly easy task since >> they are simple >> permission checks. >> >> More advanced tasks include: >> 1) re-factoring specific permission checking code >> for content >> creation and modification >> 2) re-factoring specific permission checking code >> for party creation >> and modification >> ... orders, workefforts, etc. >> >> Before anyone jumps in on any of these, a group >> discussion would be >> in order. It seems that there may be certain areas >> where we have >> current permission checking which we may not want to >> continue. For >> example, it may not make sense to require >> permissions to create a >> workeffort, or a party; as long as the user has an >> account and is >> authenticated. These are topic for future discussion >> when the time >> comes. >> >> This is going to take quite a while to do, so we'll >> probably start >> with creating a top level JIRA issue as an overview >> of the entire >> 'project'. Then create sub-tasks for each specific >> iteration of re- >> factoring. >> >> This entire 'project' will be tracked through JIRA >> issue: >> https://issues.apache.org/jira/browse/OFBIZ-609 >> >> If anyone is specifically involved in extending or >> developing on top >> of any specific area, this is a good time to get >> involved with these >> changes as they will ultimately effect you down the >> road. >> >> I'm hoping to see a number of you get involved with >> this as it will >> ultimately effect workflows for vertical >> applications and extensions >> to OOTB OFBiz. >> >> Please feel free to comment and discuss, design >> decisions should be >> placed in JIRA as well. Sub tasks can be created >> with OFBIZ-609 and >> please feel free to do so. >> >> Andrew >> >> > |
| Free forum by Nabble | Edit this page |