portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Proposal for changes in portal permissions implementation
Date Wed, 18 Jan 2006 23:52:07 GMT
I've been looking at the portal permissions and how they are used and  
think a few things can be simplified and speeded up.  If there are no  
objections to this general direction I will prepare an initial patch.

1. FolderPermission duplicates the parseActions method from  
PortalResourcePermission, and in fact calls it's copy again.  I think  
this can be eliminated.

2. PortalResourcePermission.parseActions seems to have some rather  
odd code:

                 if (token.equals(JetspeedActions.VIEW))
                     mask |= JetspeedActions.MASK_VIEW;
                 else if (token.equals(JetspeedActions.VIEW) ||  
                     mask |= JetspeedActions.MASK_VIEW;
I think this can be simplified.

3. I may not have found all the constructor uses, but I think that  
subject should be removed from all the portal permissions.  I haven't  
found any uses of the constructor including a non-null subject  
(although I might have missed some).  In addition to the resulting  
simplification, I believe the subject has no place in the  
permissions.  The JACC defined permissions for web and ejb do not  
include a subject.  JACC does allow for unchecked permissions, which  
are difficult to imagine if the permissions involved may include a  
subject.  I think a generally more satisfactory approach is to rely  
on the policy implementation to determine the subject itself.

4. Currently each construction of a  portal permission involves  
string parsing to decipher an actions string.  It looks to me as if  
this can occur hundreds of times for a medium sized portal page.   
Futhermore, this action string appears to be constructed using ad-hoc  
string manipulations in AbstractBaseElement.checkPermissions(String  
actions).  Similarly, the constraints implementation seems to do an  
enormous amount of string comparison to match actions.  I think that  
this can be entirely converted to integer masks with bitwise  
operations.  I'd propose to do this in steps, starting with the  
permissions and working backwards until I hit the contraints  
implementation, then converting it.

5. Some of the constants are duplicated between SecuredResource and  

Comments? Would these be seen as improvements to jetspeed and be  
likely to be applied?

Many thanks
david jencks

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message