portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Security for Portlet State (customize, maximize, minimize, close) not working
Date Wed, 22 May 2002 15:00:14 GMT


> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Wednesday, May 22, 2002 7:23 AM
> To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> Subject: Security for Portlet State (customize, maximize, 
> minimize, close) not working
> 
> 
> Define the role "user" permissions in the admin interface - 
> leave only "view" checked.
> 
> Portlets for a user (the user has role "user" only) still 
> have minimize, maximize, close, configure icons.
> 
> When VelocityPortletContril.buildActionList() checks permissions:
> 
> StateFullPortletWrapper.allowCustomize()
> PortletWrapper.checkPermission()
> JetspeedSecurity.checkPermission()
> JetspeedDBSecurity.checkPermission() (line 222)
> JetspeedDBSecurity.checkPermission() (line 234)
> 
> Here it check's the RegistryEntry for the portlet for 
> security, and seing none, calls "checkDefaultPermission()".
> 
> If it had seen a role for the Entry, and the user's acl has 
> the role, it goes on to call "checkPermission()".
> 
> * Why the two different calls?
> 
> Further tracking reveals... In checkDefaultPermissions(), we 
> get the set of permissions for the 
> "CONFIG_DEFAULT_PERMISSION_LOGGEDIN"., which is "*". The "*" 
> matches the permission and it is granted.  WRONG!
> 
> * Why are we going for default permissions, when I have a 
> logged in user with an ACL?
> 
> * * *
> 
> Proposal: This code:
> 
>     public boolean checkPermission(RunData runData, String 
> permission, RegistryEntry entry)
> 
> In JetspeedDBSecurityService is wrong.  It's the only place that
> checkDefaultPermission() is called, and I believe it should 
> not be doing so. checkPermission(rundata, premission) seems 
> the proper call.  Just because an Entry has no specific role, 
> doesn't mean that we should *ignore* the user's role derived 
> ACL, right?
> 
> I'll fix this - but if anyone has another opinion, please speak up!
> 

I see the logic of the way it is now. 
If no security is defined for the entry, then use the default settings
from the JRP.

What your saying is that if there is no security entry, then check to
see if any of the user's roles has the permission, and grant access
based on that check.

My original attention was to skip all security checks if no security was
defined for a resource, and always grant access.
I think I've stated before that my opinion is that portlet security
checks should be optional and should not be executed if they are
disabled (by default)
At that point I was told to go work for M$, oh well... :)

Perhaps you can make your approach part of the JRP configuration?

> ****************************************
> 
> Another thing - When BasePortletSet.allowCustommize() is 
> called, why does it check for "PERMISSION_INFO" permission?  
> Does anyone know what "info" means? Why is this not 
> "PERMISSION_CUSTOMIZE"?

Seems like a bug (and an easy fix)

> 
> Thanks.
> 
> - Glenn
>  
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> --------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message